Unknown option: "-5" Unix manual page for pam.conf. (host=minya system=Darwin)
PAM.CONF(5)                 BSD File Formats Manual                PAM.CONF(5)

NAME
     pam.conf -- PAM policy file format

DESCRIPTION
     The PAM library searches for policies in the following files, in decreas-
     ing order of preference:

     1.   /etc/pam.d/service-name

     2.   /etc/pam.conf

     3.   /usr/local/etc/pam.d/service-name

     4.   /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 pre-
     fixed 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 suc-
                 cess 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 suc-
                 cess 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 suc-
                 cess of later modules.

     optional    If this module succeeds, the result of the chain will be suc-
                 cess 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 (speci-
     fied 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
     pam(3)

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 Smorgrav <des@FreeBSD.org>.

BSD                              June 16, 2005                             BSD