To show how the theory behind PAM works, consider the PAM configuration of sshd as a practical example:
Example 2.2. PAM Configuration for sshd (/etc/pam.d/sshd
)
#%PAM-1.0auth required pam_nologin.so
auth include common-auth
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
Declares the version of this configuration file for PAM 1.0. This is merely a convention, but could be used in the future to check the version. | |
Checks, if the file | |
Refers to the configuration files of four module types:
| |
Sets the login uid process attribute for the process that was authenticated. |
By including them instead of adding each module separately to the respective PAM configuration, you automatically get an updated PAM configuration when an administrator changes the defaults. Formerly, you had to adjust all configuration files manually for all applications when changes to PAM occurred or a new application was installed. Now the PAM configuration is made with central configuration files and all changes are automatically inherited by the PAM configuration of each service.
The first include file (common-auth
) calls three
modules of the auth
type:
pam_env.so
,
pam_gnome_keyring.so
and
pam_unix2.so
. See
Example 2.3, “Default Configuration for the auth
Section”.
Example 2.3. Default Configuration for the auth
Section
auth required pam_env.so auth optional pam_gnome_keyring.so auth required pam_unix2.so
The first one, pam_env.so
, loads
the file /etc/security/pam_env.conf
to set the
environment variables as specified in this file. This can be used to set
the DISPLAY
variable to the correct value,
because the pam_env
module knows
about the location from which the login is taking place. The second one
automatically unlocks the GNOME keyring when necessary. The last one,
pam_unix2
, checks the user's
login and password against /etc/passwd
and
/etc/shadow
.
The whole stack of auth
modules is processed before
sshd gets any feedback about whether the login has succeeded. Given that
all modules of the stack have the required
control
flag, they must all be processed successfully before sshd receives a
message about the positive result. If one of the modules is not
successful, the entire module stack is still processed and only then is
sshd notified about the negative result.
As soon as all modules of the auth
type have been
successfully processed, another include statement is processed, in this
case, that in Example 2.4, “Default Configuration for the account
Section”.
common-account
contains just one module,
pam_unix2
. If pam_unix2
returns the
result that the user exists, sshd receives a message announcing this
success and the next stack of modules (password
) is
processed, shown in Example 2.5, “Default Configuration for the password
Section”.
Example 2.5. Default Configuration for the password
Section
password requisite pam_pwcheck.so nullok cracklib password required pam_unix2.so nullok use_authtok
Again, the PAM configuration of sshd involves just an include statement
referring to the default configuration for password
modules located in common-password
. These modules
must successfully be completed (control flags
requisite
and required
) whenever
the application requests the change of an authentication token.
Changing a password or another authentication token requires a security
check. This is achieved with the pam_pwcheck
module.
The pam_unix2
module used afterwards carries over
any old and new passwords from pam_pwcheck
, so the
user does not need to authenticate again after changing the password.
This procedure makes it impossible to circumvent the checks carried out
by pam_pwcheck
. Whenever the
account
or the auth
type are
configured to complain about expired passwords, the
password
modules should also be used.
Example 2.6. Default Configuration for the session
Section
session required pam_limits.so session required pam_unix2.so session optional pam_umask.so
As the final step, the modules of the session
type
(bundled in the common-session
file) are called to
configure the session according to the settings for the user in question.
The pam_limits
module loads the file
/etc/security/limits.conf
, which may define limits
on the use of certain system resources. The
pam_unix2
module is processed again. The
pam_umask
module can be used to set the file mode
creation mask. Since this module carries the optional
flag, a failure of this module would not affect the successful completion
of the entire session module stack. The session
modules are called a second time when the user logs out.