User Classes

Each OpenBSD user has a login class that defines limits on that user's access to system resources, how their environment behaves, and how users in that class authenticate. When you change the characteristics of a class, those limits affect all users in the class. All login classes are defined in /etc/login.conf.

You can change a user's class by running "chpass username" as root. Just put the class name in the "class" space provided, as shown in "Editing Users."

The Default Login Class

Whenever you create an account with adduser(8), that user is automatically assigned to the "default" class. The simplest way to manage login classes is to have the default class be the most commonly used class on your system. If your computer is an email server with a handful of administrators and several hundred mail users, set up the default class appropriately for the common case — the mail users. You can manually change the administrator's classes to a more appropriate one more easily than you can edit all those hundreds of users.

Class Definitions

Each class definition consists of a series of variable assignments. When a user logs in, login(1) uses these variables to establish the user's resource limits and environment setup. 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 marker, indicating that the computer should ignore the line break. Humans don't like 500 character lines of text, after all!

The standard /etc/login.conf starts with the "default" class. This gives the average user fairly broad access to the system. If you're running a modern system with gigabytes of RAM, you might find them too restrictive. If your OpenBSD box is a Pentium 166, however, these settings will basically give every user unlimited access to all system resources. If users consuming resources is a serious concern, you might well want to edit these settings. Here's a sample of the beginning of a login class.

 default:\         :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\         :umask=022:\         :datasize-max=256M:\ ... 

There are many more variables in a login class, but this should be enough to give you the idea. You can completely change a user's experience by assigning him to the class that configures his login environment as you desire.

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

      :requirehome:\ 

Legal Values for /etc/login.conf Variables

You can give any of the following values to a login.conf variable assignment.

• Afull path to a text file.

• A comma-separated list of values.

• A number.

• A space-separated list of path names. If a ~ is the first character in a path name, the ~ is replaced by that particular user's home directory.

• A full path to a program.

• A size, either in bytes (default), kilobytes (k), or megabytes (m).

• A time, in seconds (default), minutes (m), hours (h), days (d), weeks (w), or years (y).

Some variables, of course, require particular sorts of values. A path to the home directory must be a full path, while the amount of memory the user may use cannot be a full path. In most cases, the legitimate answers are fairly obvious.

Note

On many BSD systems, you must use cap_mkdb(8) to build a database file containing the values in /etc/login.conf for the changes to take effect. This is not necessary in OpenBSD; programs can parse /etc/login.conf directly. If you run cap_mkdb(8) on /etc/login.conf once, however, you must either continue to use it thereafter or remove the database file.

OpenBSD's default /etc/login.conf contains a few different classes of users. If you want an idea of what sort of restrictions to put on users for various situations, check that file. Here, we're just going to discuss some of the commonly changed items.

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. You can also give different login classes different resource limits.

Resource limits are frequently tied to each process. If you allow each process to use up to 20MB of RAM, and you allow each user to start 20 processes, one user could theoretically consume up to 400MB of memory. Here are several popular resource-limiting login.conf variables.

coredumpsize	The maximum size of any core dump
cputime	The maximum CPU time any process may use
datasize	The maximum memory size of data that can be consumed by one process
filesize	The maximum size of any file
stacksize	The maximum amount of memory on the stack usable by a process
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

The login.conf mechanism supports both advisory (or 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 absolutes, and the user cannot exceed them.

To specify a current limit, add -cur to the limit name. To make a hard limit, add -max. For example, to limit the number of processes a user can have to 60, but give them a warning when they've used up half the maximum, you could do this:

      :maxproc-cur=30:\      :maxproc-max=60:\ 

If you don't specify either -cur or -max, limits are hard limits and cannot be exceeded by the user.

Default Environment Setting

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. Here are some common environment settings.

hushlogin	If present, no system information is given out during the initial login
ignorenologin	If present, the user can log in even when /etc/nologin exists
nologin	If present, the user cannot login
path	The default search path for programs
priority	The default process priority, or niceness
requirehome	If present, the user must have a valid home directory to log in
setenv	A list of default environment variables
shell	The shell given to the user; overrides the one in /etc/passwd
term	The default terminal type, if nothing else tries to set a terminal type
umask	The default umask
welcome	The file containing a message displayed to the user upon login

FTP Options

You can "chroot" FTP users to their home directory via the text file /etc/ftpchroot, but if you have a lot of FTP-only users you'll be better off using a login class to contain them. It is far more maintainable in the long run. Here are the FTP-affecting login.conf variables:

ftpchroot	If present, a FTP user is automatically chrooted into their login directory (by default, their home directory)
ftp-dir	The full path to a login directory for FTP users, to give several FTP users a common directory

If you chroot FTP users it's a good idea to tell them so with a "welcome" message (as described under "Default Environment Settings").

Controlling Password and Login Options

You can control various password operations in /etc/login.conf. Unlike the environment setup, many of these can only be set in this file. OpenBSD also includes some very extensive methods to control how authentication works: see Authentication. Here are some common options for boring password authentication.

localcipher

This controls the password encryption method. This defaults to blowfish hashing, but you could set this to "old" for compatibility with the 56-bit DES hashes used in many older versions of UNIX.

login-backoff

This controls how quickly a user can try to log in. After this many login attempts, the login program starts to slow down how often it offers a login prompt.

passwordcheck

This gives the full path to an external program that will validate new passwords for quality. OpenBSD expects to pass the password to the program on standard input. The program is expected to return a 0 if the password is adequate or a 1 if the password is inadequate.

passwordtime

This is the lifetime of a password and can be used to enforce regular password changes.

minpasswordlen

This is the minimum length of a password.

Authentication Methods

You can also choose valid authentication methods in /etc/login.conf. OpenBSD uses "BSD Authentication," which works in a different manner than the popular Pluggable Authentication Modules used in quite a few open-source operating systems. You just identify the authentication method you want in /etc/login.conf, and OpenBSD will attempt to authenticate users by that method. It couldn't be easier than that!

Merely setting an authentication mechanism does not configure the authentication method — it merely tells the system to use that authentication method. For example, telling OpenBSD to authenticate a certain class of users via Kerberos V doesn't magically set up a Kerberos domain. Accounts who use a particular authentication method will be locked out if that authentication mechanism is unavailable.

Some authentication methods are simply not compatible with some protocols, so not all authentication methods work with all programs that provide logins. For example, while SSH works with cryptocards, it doesn't work with the password-changing "lchpass" authentication method. You need to check the man page for each authentication method for bugs and test unusual combinations.

Some of these authentication methods require additional login.conf variables, which are described in the manual page for that authentication method. For example, if you want to use Radius authentication, you need to tell login.conf where to find your Radius server. The manual page that describes the necessary configuration is given in the following table of common authentication methods. Here are the actual authentication methods supported by OpenBSD's BSD Authentication.

krb4-or-pwd	Try Kerberos IV, then the local password file (see kerberos(1))
krb5-or-pwd	Try Kerberos V, then the local password file (see kerberos(1))
passwd	Use the local password file
krb4	Use Kerberos IV (see kerberos(1))
krb5	Use Kerberos V (see kerberos(1))
chpass	Do not log the user in, but instead change their Kerberos password or their local password if Kerberos is unavailable (see login_chpass(8))
lchpass	Do not log the user in, but instead change their local password (see login_lchpass(8))
radius	Use Radius authentication (see login_radius(8))
skey	Use S/Key (see skey(1))
activ	Use ActivCard X9.9 token-based authentication (see login_activ(8))
snk	Use Digital Pathways SecureNet Key authentication (see login_snk(8))
token	Use a generic X9.9 token authentication (see login_token(8)

Using Authentication Methods

Authentication methods are set by login.conf's auth variable, with a commaseparated list.

      :auth=skey,passwd:\ 

One interesting thing is the ability to specify different authentication methods based on the service the user is connecting to. You can specify a "service name" after the "auth" keyword, to state that a set of authentication methods only applies to that particular service. For example, to allow only password authentication for FTP, you could use this:

      :auth-ftp=passwd:\ 

Here are a few of the commonly used authentication services:

auth	Default used for all login requests that have no specific service attached
auth-ftp	FTP
auth-ssh	SSH
auth-su	su(1) authentication

For example, you could allow a user to log in with either their local password or S/Key, but if they want to use su(1) to become root, they must authenticate with S/Key. Here's a snippet from login.conf implementing that:

      :auth=passwd,skey:\      :auth-su=skey:\ 

Note

The default /etc/login.conf uses termcap(5) format. Termcap is powerful and flexible, and it can be confusing to the beginner — entire books have been written about it. The authentication entries in the default login classes use termcap expansions, but you can easily replace those with explicit declarations as we use in this section. Investing time in learning termcap(5) will enhance your sysadmin skills, but is beyond our scope here.