NAME
pam.conf
—
PAM policy file format
DESCRIPTION
The PAM library searches for policies in the following files, in decreasing order of preference:
- /etc/pam.d/service-name
- /etc/pam.conf
- /usr/local/etc/pam.d/service-name
- /usr/local/etc/pam.conf
If none of these locations contains a policy for the given
service, the default
policy is used instead, if it
exists.
Entries in per-service policy files must be of one of the two forms below:
function-class control-flag module-path [arguments ...]
function-class include
other-service-name
Entries in pam.conf-style policy files are of the same form, but are prefixed by an additional field specifying the name of the service they apply to.
In both types of policy files, blank lines are ignored, as is
anything to the right of a ‘#
’
sign.
The function-class field specifies the class of functions the entry applies to, and is one of:
auth
- Authentication functions (pam_authenticate(3), pam_setcred(3))
account
- Account management functions (pam_acct_mgmt(3))
session
- Session handling functions (pam_open_session(3), pam_close_session(3))
password
- Password management functions (pam_chauthtok(3))
The control-flag field determines how the result returned by the module affects the flow of control through (and the final result of) the rest of the chain, and is one of:
required
- If this module succeeds, the result of the chain will be success unless a later module fails. If it fails, the rest of the chain still runs, but the final result will be failure regardless of the success of later modules.
requisite
- If this module succeeds, the result of the chain will be success unless a later module fails. If it module fails, the chain is broken and the result is failure.
sufficient
- If this module succeeds, the chain is broken and the result is success. If it fails, the rest of the chain still runs, but the final result will be failure unless a later module succeeds.
binding
- If this module succeeds, the chain is broken and the result is success. If it fails, the rest of the chain still runs, but the final result will be failure regardless of the success of later modules.
optional
- If this module succeeds, the result of the chain will be success unless a later module fails. If this module fails, the result of the chain will be failure unless a later module succeeds.
There are two exceptions to the above:
sufficient
and binding
modules are treated as optional
by
pam_setcred(3), and in the PAM_PRELIM_CHECK
phase of pam_chauthtok(3).
The module-path field specifies the name, or optionally the full path, of the module to call.
The remaining fields are passed as arguments to the module if and when it is invoked.
The include
form of entry causes entries
from a different chain (specified by
other-system-name) to be included in the current one.
This allows one to define system-wide policies which are then included into
service-specific policies. The system-wide policy can then be modified
without having to also modify each and every service-specific policy.
SEE ALSO
STANDARDS
X/Open Single Sign-On Service (XSSO) - Pluggable Authentication Modules, June 1997.
AUTHORS
The OpenPAM library was developed for the FreeBSD Project by ThinkSec AS and Network Associates Laboratories, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (“CBOSS”), as part of the DARPA CHATS research program.
This manual page was written by Dag-Erling Smørgrav ⟨des@FreeBSD.org⟩.