LOGIN.CONF(5) | File Formats Manual | LOGIN.CONF(5) |
login.conf
— login
class capability database
/etc/login.conf |
The login.conf
file describes the various
attributes of login classes. A login class determines what styles of
authentication are available as well as session resource limits and
environment setup. While designed primarily for the
login(1) program, it is also
used by other programs, such as
ftpd(8), to determine what
means of authentication are available. It is also used by programs which
need to set up a user environment.
A special record, “default”, in /etc/login.conf is used for any user without a valid login class in /etc/master.passwd.
Sites with very large /etc/login.conf files may wish to create a database version of the file, /etc/login.conf.db, for improved performance. Using a database version for small files does not result in a performance improvement. To build /etc/login.conf.db from /etc/login.conf the following command may be used:
# cap_mkdb
/etc/login.conf
Note that cap_mkdb(1) must be run after each edit of /etc/login.conf to keep the database version in sync with the plain file.
Refer to getcap(3)
for a description of the file layout. All entries in the
login.conf
file are either boolean or use a
‘=
’ to separate the capability from
the value. The types are described after the capability table.
Name | Type | Default | Description |
approve | program | Default program to approve login. | |
approve-service | program | Program to approve login for service. | |
auth | list | passwd |
Allowed authentication styles. The first value is the default styles. |
auth-type | list | Allowed authentication styles for the authentication type type. | |
classify | program | Classify type of login. | |
copyright | file | File containing additional copyright information. | |
coredumpsize | size | Maximum coredump size limit. | |
cputime | time | CPU usage limit. | |
datasize | size | Maximum data size limit. | |
expire-warn | time | 2w |
If the user's account will expire within this length of time then warn the user of this. |
filesize | size | Maximum file size limit. | |
hushlogin | bool | false |
Same as having a $HOME/.hushlogin file. See login(1). |
ignorenologin | bool | false |
Not affected by nologin files. See login(1). |
localcipher | string | blowfish,8 | The cipher to use for encrypting passwords. Refer to crypt_newhash(3) for possible values. |
login-backoff | number | 3 | After login-backoff unsuccessful login attempts during a single session, login(1) will start sleeping a bit in between attempts. |
login-timeout | time | 300 | Number of seconds before
login(1) times out at the
password prompt. Note that this setting is only valid for the
default record.
|
login-tries | number | 10 | Number of tries a user gets to successfully login before login(1) closes the connection. |
stacksize | size | Maximum stack size limit. | |
maxproc | number | Maximum number of processes. | |
memorylocked | size | Maximum locked in core memory size limit. | |
memoryuse | size | Maximum in core memoryuse size limit. | |
minpasswordlen | number | 6 | The minimum length a local password may be. If a negative value or zero, no length restrictions are enforced. Used by the passwd(1) utility. |
nologin | file | If the file exists it will be displayed and the login session will be terminated. | |
openfiles | number | Maximum number of open file descriptors per process. | |
password-dead | time | 0 |
Length of time a password may be expired but not quite dead yet. When set (for both the client and remote server machine when doing remote authentication), a user is allowed to log in just one more time after their password (but not account) has expired. This allows a grace period for updating their password. |
password-warn | time | 2w |
If the user's password will expire within this length of time then warn the user of this. |
passwordcheck | program | An external program that checks the quality of the password. The password is passed to the program on stdin. An exit code of 0 indicates that the quality of the password is sufficient, an exit code of 1 signals that the password failed the check. | |
passwordtime | time | The lifetime of a password in seconds, reset every time a user changes
their password. When this value is exceeded the user will no longer be
able to login unless the password-dead option has
been specified. Used by the
passwd(1) utility.
|
|
passwordtries | number | 3 | The number of times the passwd(1) utility enforces a check on the password. If 0, the new password will only be accepted if it passes the password quality check. |
path | path | value of _PATH_DEFPATH |
Default search path. See /usr/include/paths.h. |
priority | number | Initial priority (nice) level. | |
requirehome | bool | false |
Require home directory to login. |
setenv | envlist | A list of environment variables and associated values to be set for the class. | |
shell | program | Session shell to execute rather than the shell specified in the password
file. The SHELL environment variable will contain
the shell specified in the password file.
|
|
tc | string | Interpolate/expands records from corresponding login.conf. See getcap(3). | |
term | string | su |
Default terminal type if not able to determine from other means. |
umask | number | 022 |
Initial umask. Should always have a leading 0 to
ensure octal interpretation. See
umask(2).
|
vmemoryuse | size | Maximum virtual memoryuse size limit. | |
welcome | file | /etc/motd | File containing welcome message. |
The resource limit entries (cputime, filesize, datasize, stacksize, coredumpsize, memoryuse, memorylocked, maxproc, and openfiles) actually specify both the maximum and current limits (see getrlimit(2)). The current limit is the one normally used, although the user is permitted to increase the current limit to the maximum limit. The maximum and current limits may be specified individually by appending a -max or -cur to the capability name (e.g., openfiles-max and openfiles-cur).
OpenBSD will never define capabilities
which start with x-
or X-
,
these are reserved for external use (unless included through contributed
software).
The argument types are defined as:
variable
=value. If no
value is specified, the ‘=’ is optional. A
~
in the path name is expanded to the user's home
directory if it is at the end of a string or is followed by a slash
(‘/’) or the user's login name. A $
in the path name is expanded to the user's login name.0x
implies the number is
expressed in hexadecimal. A leading 0
implies the
number is expressed in octal. Any other number is treated as decimal.~
is only expanded at the
beginning of a path name.b
, k
,
m
, g
or
t
to indicate that the value is in 512-byte
blocks, kilobytes, megabytes, gigabytes, or terabytes, respectively.For example, to indicate 1 and 1/2 hours, the following string
could be used: 1h30m
.
OpenBSD uses BSD Authentication, which is made up of a variety of authentication styles. The authentication styles currently provided are:
activ
chpass
crypto
lchpass
passwd
radius
reject
skey
snk
token
yubikey
Local authentication styles may be added by creating a login
script for the style (see below). To prevent collisions with future official
BSD Authentication style names, all local style
names should start with a dash (-). Current plans are for all official
BSD Authentication style names to begin with a lower
case alphabetic character. For example, if you have a new style you refer to
as slick
then you should create an authentication
script named /usr/libexec/auth/login_-slick using
the style name -slick
. When logging in via the
login(1) program, the syntax
user:-slick
would be used.
Authentication requires several pieces of information:
The service type login
is appropriate
for most situations. Two other service types,
challenge
and response
,
are provided for use by programs like
ftpd(8) and
radiusd(8). If no
service type is specified, login
is used.
The program requesting authentication must specify a username and
an authentication style. (For example,
login(1) requests a username
from the user. Users may enter usernames of the form
“user:style” to optionally specify the authentication style.)
The requesting program may also specify the type of authentication that will
be done. Most programs will only have a single type, if any at all, i.e.,
ftpd(8) will always request the
ftp
type authentication, and
su(1) will always request the
su
type authentication. The
login(1) utility is special in
that it may select an authentication type based on information found in the
/etc/ttys file for the appropriate tty (see
ttys(5)).
The class to be used is normally determined by the
class
field in the password file (see
passwd(5)).
The class is used to look up a corresponding entry in the
login.conf file. If an authentication type is
defined and a value for
auth-
type exists in that
entry, it will be used as a list of potential authentication styles. If an
authentication type is not defined, or
auth-
type is not specified for
the class, the value of auth
is used as the list of
available authentication styles.
If the user did not specify an authentication style the first style in the list of available styles is used. If the user did specify an authentication style and the style is in the list of available styles it will be used, otherwise the request is rejected.
For any given style, the program /usr/libexec/auth/login_style is used to perform the authentication. The synopsis of this program is:
/usr/libexec/auth/login_
style
[-v
name=value]
[-s
service]
username class
The -v
option is used to specify arbitrary
information to the authentication programs. Any number of
-v
options may be used. The
login(1) program provides the
following through the -v
option:
auth_type
fqdn
-h
option.hostname
local_addr
-L
option.lastchance
login
remote_addr
-R
option.style
The su(1) program
provides the following through the -v
option:
wheel
When the authentication program is executed, the environment will
only contain the values PATH=/bin:/usr/bin
and
SHELL=/bin/sh
. File descriptor 3 will be open for
reading and writing. The authentication program should write one or more of
the following strings to this file descriptor:
authorize secure
reject
reject challenge
challenge
.reject silent
remove
filesetenv
name valueunsetenv
namevalue
name value\n
\r
\t
\
xxx\
cThe following values are currently defined:
In order for authentication to be successful, the authentication
program must exit with a value of 0 as well as provide an
authorize
or authorize root
statement on file descriptor 3.
An authentication program must not assume it will be called as root, nor must it assume it will not be called as root. If it needs special permissions to access files it should be setuid or setgid to the appropriate user/group. See chmod(1).
When an authentication program is called with a service of
challenge
it should do one of three things:
If this style of authentication supports challenge response it
should set the internal variable challenge
to be the
appropriate challenge for the user. This is done by the
value
command listed above. The program should also
issue a reject challenge
and then exit with a 0
status. See the section on responses below.
If this style of authentication does not support challenge
response, but does support the response
service
(described below) it should issue reject silent
and
then exit with a 0 status.
If this style of authentication does not support the
response
service it should simply fail, complaining
about an unknown service type. It should exit with a non-zero status.
When an authentication program is called with a service of
response
, and this style supports this mode of
authentication, it should read two null terminated strings from file
descriptor 3. The first string is a challenge that was issued to the user
(obtained from the challenge
service above). The
second string is the response the user gave (i.e., the password). If the
response is correct for the specified challenge, the authentication should
be accepted, else it should be rejected. It is possible for the challenge to
be an empty string, which implies the calling program did first obtain a
challenge prior to getting a response from the user. Not all authentication
styles support empty challenges.
An approval program has the synopsis of:
-v
name=value]
username class serviceJust as with an authentication program, file descriptor 3 will be
open for writing when the approval program is executed. The
-v
option is the same as in the authentication
program. Unlike an authentication program, the approval program need not
explicitly send an authorize
or
authorize root
statement, it only need exit with a
value of 0 or non-zero. An exit value of 0 is equivalent to an
authorize
statement, and non-zero to a
reject
statement. This allows for simple programs
which have no information to provide other than approval or denial.
A classify program has the synopsis of:
-v
name=value]
[-f
] [user]See login(1) for a
description of the -f
, option. The
-v
option is the same as for the authentication
programs. The user is the username passed to
login(1) login, if any.
The typical job of the classify program is to determine what authentication type should actually be used, presumably based on the remote IP address. It might also re-specify the hostname to be included in the utmp(5) file, reject the login attempt outright, or even print an additional login banner (e.g., /etc/issue).
The classify entry is only valid for the
default
class as it is used prior to knowing who the
user is. The classify script may pass environment variables or other
commands back to login(1) on
file descriptor 3, just as an authentication program does. The two variables
AUTH_TYPE
and REMOTE_NAME
are used to specify a new authentication type (the type must have the form
auth-
type) and override the
-h
option to login, respectively.
cap_mkdb(1), login(1), auth_subr(3), authenticate(3), getcap(3), login_cap(3), passwd(5), ttys(5), ftpd(8)
March 30, 2016 | OpenBSD-6.0 |