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
Po pam_authenticate3,
pam_setcred3
Pc
account
Account management functions
(pam_acct_mgmt3
)
session
Session handling functions
Po pam_open_session3,
pam_close_session3
Pc
password
Password management functions
(pam_chauthtok3
)
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_setcred3,
and in the
PAM_PRELIM_CHECK
phase of
pam_chauthtok3.
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.
"X/Open Single Sign-On Service (XSSO) - Pluggable Authentication Modules"
"June 1997"
AUTHORS
The OpenPAM library was developed for the
Fx 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
An Dag-Erling Sm/orgrav Aq [email protected] .
