To show how the theory behind PAM works, consider the PAM configuration of sshd as a practical example:
Example 21.1. PAM Configuration for sshd
#%PAM-1.0 auth required pam_unix2.so # set_secrpc auth required pam_nologin.so auth required pam_env.so account required pam_unix2.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok session required pam_unix2.so none # trace or debug session required pam_limits.so # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE) #session optional pam_resmgr.so fake_ttyname
sshd first calls the three modules of the auth type. The first one, pam_unix2, checks the user's login and password against /etc/passwd and /etc/shadow. The next module (pam_nologin) checks whether the file /etc/nologin exists. If it does, no user other than root may log in. The third module is pam_env, which loads the file /etc/security/pam_env.conf to set the environment variables as specified in the 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 whole stack of auth modules is processed before sshd gets any feedback about whether the login has succeeded or not. 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.
The next stack of modules includes all the account type modules, which check whether the user has general permission to use the requested service. This again involves the successful processing of the modules pam_unix2 and pam_nologin (required). If pam_unix2 returns the result that the user exists and if pam_nologin returns the result that the user may indeed log in, sshd receives a message about the success, after which the next module stack is processed.
The following two modules are of the password type and must also be successfully completed (control flag 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, which uses the CrackLib library to check whether the password is secure, warning the user if he has chosen a password which is lacking in any respect (too short, too simple). The previously used pam_unix2 module carries over any old and new passwords from pam_pwcheck, so the user does not have to authenticate again. This also makes it impossible to circumvent the checks carried out by pam_pwcheck. The modules of the password type should be used wherever the preceding modules of the account or the auth type are configured to complain about an expired password.
As the final step, the modules of the session type are called to configure the session according to the settings for the user in question. Although pam_unix2 is processed again, it has no practical consequences due to its none option. The pam_limits module loads the file /etc/security/limits.conf, which may define limits on the use of certain system resources. The session modules are called a second time when user logs out.