Each of these elements are explained in the following sections.
14.3.1. Module Interface
There are four types of PAM module interfaces which correlate to
different aspects of the authorization process:
auth — These modules authenticate the
user by, for example, asking for and checking a password. Modules
with this interface can also set credentials, such as group
membership or Kerberos tickets.
account — These modules verify that
access is allowed. For example, it can check if a user account is
expired or is allowed to log in at a particular time of day.
password — These modules set and verify
session — These modules configure and
manage user sessions. Modules with this interface can also perform
additional tasks that are needed to allow access, like mounting a
user's home directory and making the user's mailbox available.
An individual module can provide any or all module interfaces. For
instance, pam_unix.so provides all four
In a PAM configuration file, the module interface is the first
field defined. For example a typical line in a configuration may look
auth required /lib/security/pam_unix.so
This instructs PAM to use the pam_unix.so
module's auth interface.
188.8.131.52. Stacking Modules
Module interface directives can be stacked, or
placed upon one another, so that multiple modules are used together
for a one purpose. For this reason, the order in which the modules
are listed is very important to the authentication process.
Stacking makes it very easy for an administrator to require specific
conditions to exist before allowing the user to authenticate. For
example, rlogin normally uses five stacked
auth modules, as seen in its PAM
Before someone is allowed to use rlogin, PAM
verifies that the /etc/nologin file does not
exist, that they are not trying to log in remotely as a root user
over an unencrypted network connection, and that any environmental
variables can be loaded. Then, if a successful
rhosts authentication is performed, the
connection is allowed. If the rhosts
authentication fails, then a standard password authentication is
14.3.2. Control Flag
All PAM modules generate a success or failure result when
called. Control flags tell PAM what do with the result. Since modules
can be stacked in a particular order, control flags decide how important
the success or failure of a particular module is to the overall
goal of authenticating the user to the service.
There are four predefined control flags:
required — The module
result must be successful for authentication to continue. If a
required module result fails,
the user is not notified until results on all modules referencing
that interface are completed.
requisite — The
module result must be successful for authentication to
continue. However, if a
requisite module result fails,
the user is notified immediately with a message reflecting the
first failed requiredorrequisite module.
sufficient — The
module result is ignored if it fails. But, if a
sufficient flagged module result
is successful and no
required flagged modules above
it have failed, then no other results are required and the user
is authenticated to the service.
optional — The module result is
ignored if it fails. If the module result is successful, it does
not play a role in the overall success or failure for the module
interface. A module flagged as optional
becomes necessary for successful authentication when there are
no other modules referencing that interface. In this case, an
optional module determines the overall PAM
authentication for that interface.
The order in which required modules are called is
not critical. The sufficient and
requisite control flags cause order to become
A newer control flag syntax which allows for more precise control is
now available for PAM. Please see the PAM docs located in the
directory for information on this new syntax (where
<version-number> is the version
number for PAM).
14.3.3. Module Path
Module paths tell PAM where to find the pluggable module to be used with
the module interface specified. Usually, it is provided as the full path
to the module, such as
/lib/security/pam_stack.so. However, if the full
path is not given, then the module indicated is assumed to be in the
/lib/security/ directory, the default location for
14.3.4. Module Arguments
PAM uses arguments to pass information to a pluggable module during
authentication for some modules.
For example, the pam_userdb.so module uses
secrets stored in a Berkeley DB file to authenticate the
user. Berkeley DB is an open source database system embedded in many
applications. The module takes a db argument so
that Berkeley DB knows which database to use for the requested
A typical pam_userdb.so line within a PAM configuration
file looks like this: