name from its IP address–this process is controlled by the owner of the IP address. Although my laptop might claim a hostname of pedicular.AbsoluteBSD.com, its IP address has reverse DNS that claims it is somewhere in the home.com network. A machine in AbsoluteBSD.com will think that my laptop has a hostname that is in the home.com domain, and hence is not local. As such, I can't use the LOCAL verification method.

So, how can we tie all this together? For one thing, we can use a one−line login.access to allow administrators to log in to the server while rejecting all other remote connections:

...............................................................................................

−:ALL EXCEPT wheel:ALL

...............................................................................................

However, this might restrict your environment too tightly if, for example, your company has staff groups. Two common groups are "dns" (people who can edit domain zone files) and "www" (people who can edit Web server configurations). Servers such as these might find this login.access appropriate:

...............................................................................................

−:ALL EXCEPT wheel dns www:ALL

...............................................................................................

A common corporate Web servers' farm login.access file looks like this:

...............................................................................................

−:ALL EXCEPT wheel:console

−:ALL EXCEPT wheel dns www:ALL

...............................................................................................

Set up this entry one time, and users cannot log in unless you add them to a permitted group.

/etc/login.conf

If the all−or−nothing control of /etc/login.access doesn't fit your needs, you can provide more specific controls with /etc/login.conf. This file allows you to tweak the environment you present to specific users and limit the resources you allow them to have.

The login.conf system works by defining classes and assigning each user to a class. Each class has limits on its access to system resources. When you change the limits on the class, those limits affect all users in that class. You set a user's class when you create the user's account, and change it by running chsh username as root.

Class Definitions

Each class definition consists of a series of variable assignments. When a user logs in, login(1) checks these variables to establish the user's resource limits, accounting, and environment setup.

The default /etc/login.conf starts with the "default" class, the class used by accounts without any other class. This class gives the user basically unlimited access to system resources. If the default class fits your needs, don't adjust this file at all. (If you need to throttle users, read on.)

197

Each entry in the class definition begins and ends with a colon, although technically, each entry is all one line. The backslash character is a continuation character (indicating that the computer should ignore the line break), which allows the file to be arranged in a human−readable format. Here's a sample of the beginning of one class in a standard login.conf:

...............................................................................................

default:\

:passwd_format=md5:\

:copyright=/etc/COPYRIGHT:\

:welcome=/etc/motd:\

...

...............................................................................................

This class is called default. I've shown three variables in this class (there are more, but this is enough to give you the idea). The variable passwd_format, for example, is set to md5. Each login class contains these variables and assignments. You can change a user's experience on the system by assigning her to the class that configures her environment as you desire.

Some login.conf variables don't have a value; they change account behavior just by being present. For example, the "requirehome" variable just needs to be in the class definition to have its effect.

...............................................................................................

:requirehome:\

...............................................................................................

Making Changes Take Effect

After you edit login.conf, you must update your login database to make the changes take effect:

...............................................................................................

# cap_mkdb /etc/login.conf

...............................................................................................

FreeBSD's default /etc/login.conf includes several classes of users. If you want an idea of what sort of restrictions to put on users for various situations, check that file. The following section will give you an idea of some of the things that can be set here.

Resource Limits

Resource limits allow you to control how much of the system any one user can tie up at one time. If you have several hundred users logged in to one machine, and one of those users decides to compile 30MB of source code, that person can consume far more than his fair share of processor time and memory. By limiting the resources that one user can monopolize at one time, you can make the system more responsive for less needy users.

Resource limits are frequently tied to each process, so you need to consider that when assigning limits. If you give each process 20MB of RAM, and allow 20 processes per user, you might as well not be using resource limits at all, since you're assigning 400MB of RAM to each user. Each user class can have its own resource limits.

198

Table 9−1 describes the resource−limiting login.conf variables.

Table 9−1: Login.conf variables for limiting resource use

Variable Description

cputime The maximum CPU time any process may use

filesize The maximum size of any one file

datasize The maximum memory size of data that can be consumed by one process

stacksize The maximum amount of memory on the stack usable by a process

coredumpsize The maximum size of a core dump

memoryuse The maximum amount of memory a process can lock

maxproc The maximum number of processes the user can have running

openfiles The maximum number of open files per process

Current and Maximum Resource Limits

You can specify current and maximum resource limits. Current limits (−cur) are generally advisory, and the user can override them at will. (This works well on a cooperative system, where multiple users willingly share resources.) Maximum limits (−max) are absolute, and the user cannot raise them. You can use current limits to warn the user that they are trying to exceed the standard resource allocation.

To specify a current limit, add −cur to the limit name. To make a hard limit, add −max. For example, to set a current limit on the number of processes the user can have, do this:

If you don't specify either −cur or −max, both the current and maximum limit are set to the value you specify.

Specifying Default Environment Settings

You can also specify default environment settings in /etc/login.conf. This can be better than setting them in a user's default .cshrc or .profile, as these settings affect all user accounts immediately upon each user's next login.

All of the environment fields recognize two special characters: the tilde (~) and the dollar sign ($). The tilde (~) is replaced by the user's home directory, the dollar sign ($) by the username. For example, in the default class, the line that sets the environment variable MAIL to /var/mail/$

199

becomes /var/mail, followed by the user's username. Similarly, ~bin in the path entry points to the bin directory in the user's home directory.

Table 9−2 identifies some common environment settings.

Table 9−2: Common login.conf environment variables

Variable Description

hushlogin If present in class definition, no system information is given out during the initial login.

ignorenologin If present in class definition, the user can log in even when a /var/run/nologin file exists.

Controlling Password and Login Options

You can control various password and login options in /etc/login.conf. Unlike the environment setup, many of these can only be set in this file. Here are some common authentication options.

minpasswordlen Minpasswordlen specifies the minimum length of a password. This only takes effect the next time the user changes his or her password; it doesn't go through and check that all passwords are of this length. The following example will really, really annoy your users.

...............................................................................................

:minpasswordlen=28:\

...............................................................................................

200

passwd_format The passwd_format option sets the encryption hash used to encrypt passwords in /etc/passwd. This defaults to md5 for MD5 hashing. Other permissible options are des and blf (blowfish). DES is most useful when you want to share passwords between different operating systems. Blowfish might be an inherently cool algorithm, but it isn't really necessary unless you want to share password files between FreeBSD and OpenBSD systems.

mixpasswordcase If mixpasswordcase is present, users cannot change their passwords to contain only lowercase letters.

copyright The copyright option specifies the full path to a file containing copyright information for the system.

host.allow Users in a class with this value set can use rlogin and rsh to log in to this server from the hosts specified, much like /etc/hosts.allow permits. (This does not make rlogin or rsh safe, and should be strongly discouraged.) The entry is a comma−delimited list, and can use an asterisk (*) as a wildcard to match networks or domains. A system must appear in both /etc/hosts.allow and this entry.

...............................................................................................

:host.allow=192.168.1.*:\

...............................................................................................

host.deny This variable lists remote hosts that cannot log in using accounts in this class. This functionality overlaps /etc/login.access, allowing you to deny logins by particular accounts from particular IP addresses.

If host.deny conflicts with host.allow, host.deny takes precedence. As in host.allow, you can use an asterisk (*) as a wildcard to match entire networks or domains. Any host not listed in host.deny may connect as one of the users in the class.

times.allow Times.allow specifies the times when the user may log in. This requires a comma−delimited field of days and times. Days are given as the first two letters of the day's name (Su, Mo, Tu, We, Th, Fr, and Sa). Time is in standard 24−hour format. For example, if a user can only log in on Wednesdays, between 8 AM and 5 PM, you would use this entry:

...............................................................................................

times.allow=We8−17:\

...............................................................................................

times.deny Times.deny specifies times when the user cannot log in. Note that this does not kick a user off when he's already logged in. The format is the same as for times.allow. If times.allow and times.deny overlap, times.deny takes precedence.

Accounting Functions

You can set a variety of accounting functions in /etc/login.conf, and these functions require system accounting to be on. Accounting isn't as important today as it was when inexpensive computers cost

201