Contents
Abstract
Linux uses PAM (pluggable authentication modules) in the authentication process as a layer that mediates between user and application. PAM modules are available on a systemwide basis, so they can be requested by any application. This chapter describes how the modular authentication mechanism works and how it is configured.
System administrators and programmers often want to restrict access to certain parts of the system or to limit the use of certain functions of an application. Without PAM, applications must be adapted every time a new authentication mechanism, such as LDAP, Samba, or Kerberos, is introduced. This process, however, is rather time-consuming and error-prone. One way to avoid these drawbacks is to separate applications from the authentication mechanism and delegate authentication to centrally managed modules. Whenever a newly required authentication scheme is needed, it is sufficient to adapt or write a suitable PAM module for use by the program in question.
Every program that relies on the PAM mechanism has its own configuration
file in the directory
/etc/pam.d/
.
These files define the PAM modules used for authentication. In addition,
there are global configuration files for PAM modules under
programname
/etc/security
, which define the exact behavior of these
modules (examples include pam_env.conf
, and
time.conf
). Every application that uses a PAM module
actually calls a set of PAM functions, which then process the information in
the various configuration files and return the result to the calling
application.
To facilitate the creation and maintenance of PAM modules, common
default configuration files for the auth
,
account
, password
, and
session
modules have been introduced. These are pulled in
from every application's PAM configuration. Updates to the global PAM
configuration modules in common-*
are thus propagated
across all PAM configuration files without requiring the administrator to
update every single PAM configuration file.
The global common PAM configuration files are maintained using the pam-config tool. This tool automatically adds new modules to the configuration, changes the configuration of existing ones or deletes modules or options from the configurations. Manual intervention in maintaining PAM configurations is minimized or no longer required.
Each line in a PAM configuration file contains a maximum of four columns:
<Type of module> <Control flag> <Module path> <Options>
PAM modules are processed as stacks. Different types of modules have different purposes, for example, one module checks the password, another one verifies the location from which the system is accessed, and yet another one reads user-specific settings. PAM knows about four different types of modules:
auth
The purpose of this type of module is to check the user's authenticity. This is traditionally done by querying a password, but it can also be achieved with the help of a chip card or through biometrics (fingerprints or iris scan).
account
Modules of this type check whether the user has general permission to use the requested service. As an example, such a check should be performed to ensure that no one can log in under the username of an expired account.
password
The purpose of this type of module is to enable the change of an authentication token. In most cases, this is a password.
session
Modules of this type are responsible for managing and configuring user sessions. They are started before and after authentication to register login attempts in system logs and configure the user's specific environment (mail accounts, home directory, system limits, etc.).
The second column contains control flags to influence the behavior of the modules started:
required
A module with this flag must be successfully processed before the
authentication may proceed. After the failure of a module with the
required
flag, all other modules with the same flag
are processed before the user receives a message about the
failure of the authentication attempt.
requisite
Modules having this flag must also be processed successfully, in much the
same way as a module with the required
flag. However,
in case of failure a module with this flag gives immediate feedback
to the user and no further modules are processed. In case of success,
other modules are subsequently processed, just like any modules with the
required
flag. The requisite
flag
can be used as a basic filter checking for the existence of certain
conditions that are essential for a correct authentication.
sufficient
After a module with this flag has been successfully processed, the
calling application receives an immediate message about the success and
no further modules are processed, provided there was no preceding
failure of a module with the required
flag. The
failure of a module with the sufficient
flag has no
direct consequences, in the sense that any subsequent modules are
processed in their respective order.
optional
The failure or success of a module with this flag does not have any direct consequences. This can be useful for modules that are only intended to display a message (for example, to tell the user that mail has arrived) without taking any further action.
If this flag is given, the file specified as argument is inserted at this place.
The module path does not need to be specified explicitly, as long as the
module is located in the default directory
/lib/security
(for all 64-bit platforms supported by
openSUSEŽ, the directory is /lib64/security
). The
fourth column may contain an option for the given module, such as
debug
(enables debugging) or nullok
(allows the use of empty passwords).