This article contains excerpts from documentation to highlight and summarize key features of PAM.
PAM is a framework to service authentication & authorization requests. The PAM library
libpam which apps are linked with uses variety pluggable modules (other dynamic libraries) and configuration files to customize the behaviour. Privilege granting apps like
login use standard PAM API of
libpam to handle such requests.
PAM configuration is only applicable to apps which use PAM in their internal logic. Such apps are commonly called "PAM-aware".
Collection of libraries:
Configuration per library:
There could be other configuration files referenced by certain PAM modules. For example,
Configuration per app:
The configuration files under
/etc/pam.d directory usually have the same name as corresponding "PAM aware" app which uses it.
Official offline docs:
/usr/share/doc/pam-* man 5 pam.conf
Module-specific configuration can be found in corresponding
man-pages listed by
Configuration per each app uses list = chain of rules. The format of each rule is a space separated collection of tokens:
service type control module-path module-arguments
The presence of
/etc/pam.d directory will cause Linux-PAM to ignore
/etc/pam.d/* files and
pam.conf file is different only by service field which is absent in
(IMHO) Just like with chain of rules in IP tables, PAM configuration evolved in a programming language with custom syntax and multitude of keywords (especially those related to module arguments). This all can only be learnt by changing various examples.
The rules in the lists are "typed" by service request. Types (management groups) of rules:
auth- authenticate user
account- authorise user
session- actions at the beginning and at the end
password- update user info (commonly authentication info used by auth)
(IMHO) Although the purpose of each type is defined by explanation, it does not help much in practice without experience.
It is better to think of a stacks per each of the four types:
password-stack. The PAM library calls each of the modules in specified stack type, in turn.
type value is prepended with a minus character (
-), the PAM library will not log to the system log if it is not possible to load the module because it is missing in the system.
Each of the modules returns a pass/fail indication to the library. The PAM library combines these pass/fail results into a pass/fail result for the stack as a whole.
Control values (simple syntax):
required- Fail makes the stack immediately return fail.
requisite- Fail is remembered until the end of the stack to return fail.
sufficient- Pass makes the stack immediately return pass.
optional- Result is ignored.
include- Calls stack from specified file (similar to C-style
#includedirective - see
man 5 pam.conf)
substack- Calls stack from specified file (similar to function call in any language - see
man 5 pam.conf)
There are two types of syntax for this control field.
The simple one has a single simple keyword.
The complex one involves a square-bracketed selection of
[value1=action1 value2=action2 ...]
Each of the four keywords have an equivalent expression in terms of the complex syntax (see
man 5 pam.conf).
Module path and arguments
Module path is simply location to the shared library containing implementation (by default location is relative to
/lib*/security/). Module arguments are obviously module-specific with description in corresponding
Note that if you wish to include spaces in an argument you should surround that argument with square brackets.