Using Linux:Managing Users and Groups






-->















Previous
Table of Contents
Next




One special feature of PAM is its “stackable” nature. That is, every line in the configuration file is evaluated during the authentication process (with the exceptions shown later). Each line specifies a module that performs some authentication task and returns either a success or failure flag. A summary of the results is returned to the application program calling PAM.

Let’s examine a sample PAM configuration file, /etc/pam.d/login.


#%PAM-1.0
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_pwdb.so shadow
nullok
auth required /lib/security/pam_nologin.so
account required /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so shadow
nullok use_authtok
session required /lib/security/pam_pwdb.so


You can see that the first line begins with a hash symbol and is therefore a comment. You can ignore it.

Now go through the rest of the file line by line:


auth required /lib/security/pam_securetty.so


specifies that the module_type is auth, which means it will want a password. The control_flag is set to required, so this module must return a success or the login will fail. The module itself is the pam_securetty.so module, which verifies that logins on the root account can only happen on the terminals mentioned in the /etc/securetty file.


auth required /lib/security/pam_pwdb.so shadownullok


Similar to the previous line, this line wants to use a password for authentication, and if the password fails, the authentication process will return a failure flag to the calling application. The pam_pwdb.so module behavior is based on the module_type. In this case, the auth type allows pam_pwdb.so to do basic password checking against the /etc/passwd file. The shadow parameter tells it to check the /etc/shadow file if it is there, and the nullok parameter tells the module to allow users to change their password from an empty one to something. (Normally, it treats empty passwords as an account locking mechanism.)


auth required /lib/security/pam_nologin.so


The pam_nologin.so module checks for the /etc/nologin file. If it is present, only root is allowed to log in, and others are turned away with an error message. If the file does not exist, it always returns a success.


account required /lib/security/pam_pwdb.so


Because the module_type is account, the pam_pwdb.so module will silently check that the user is even allowed to log in (for example, has his password expired?). If all the parameters check out okay, it will return a success.


password required /lib/security/pam_cracklib.so


The password module_type account means that we will be using the pam_cracklib.so module during a password change. The pam_cracklib.so module performs a variety of checks to see whether a password is “too easy” to crack by potential intruders.


password required /lib/security/pam_pwdb.so shadow
nullok use_authtok


This is another example of the versatility of the pam_pwdb.so module. With the module_type set to password, it will perform the actual updating of the /etc/passwd file. The shadow parameters tell it to check for the existence of the /etc/shadow file and update that file if it does exist. nullok allows users to change their passwords from empty entries to real passwords. The last option, use_authtok, forces pam_pwdb.so to use the password retrieved from a previous module_type entry of password.


session required /lib/security/pam_pwdb.so


This is the fourth and final usage of the pam_pwdb.so module. This time it sends login successes and failures to the system logs because the module_type is set to session.
The other File

What happens when you need to authenticate someone for a service, but you don’t have a PAM configuration file for him? Simple. Use the /etc/pam.d/other configuration file—a sort of catch-all type of setup.
In this situation, if a user tries to authenticate himself using a PAM-aware application (for example, the FTP server) but the configuration file for it is not there (in the case of the FTP server, the /etc/pam.d/ftp file got accidentally removed), PAM will default to using the configuration file /etc/pam.d/other.
By default, the other configuration file is set to a paranoid setting so that all authentication attempts are logged and then promptly denied. It is recommended that you keep it that way.
Oh No! I Can’t Log In!
In the immortal words of Douglas Adams, “don’t panic.” Like many other configuration errors that can occur under Linux, this one can be fixed by either booting into single user mode or booting off a floppy. (See Chapter 24, “Using LILO and LOADLIN,” for details on booting into single user mode.)

After you are back into the system in single user mode, simply edit the /etc/pam.d/login file so that it contains only the following lines:


auth required /lib/security/pam_unix_auth.so
account required /lib/security/pam_unix_acct.so
password required /lib/security/pam_unix_passwd.so
session required /lib/security/pam_unix_session.so


This simplified login configuration will stick to the original UNIX authentication method, which should hopefully work well enough to get you back into the system in multiuser mode.

After you are back in multiuser mode, be sure to go back and fix the login configuration file to reflect what you really wanted to do instead of what it did—lock you out!
Debugging/Auditing
While you are debugging the PAM configuration files, be sure to keep an eye on the system log files. (Usually in /var/log.) Most of the error logging will occur there.
When you have things working the way you like, be sure to check those files for auditing information from PAM. It reports not only authentication successes but failures as well. Multiple failures for a particular person or for a range of people in a short time could indicate trouble.



Previous
Table of Contents
Next