Linux DevCenter    
 Published on Linux DevCenter (
 See this if you're having trouble printing code examples

PAM Modules

by Jennifer Vesperman

Editor's note: This is the second in a series of article on Pluggable Authentication Modules. In part one, Jennifer introduced PAM and showed how to get started. In this article, she walks us through some of the more useful modules.

Traditional user authentication is programmed directly into applications. Using PAM (Pluggable Authentication Modules), applications can be developed with a PAM interface, and the system administrator can choose any number of PAM modules to do authentication and other tasks.

PAM was designed for authentication, and it remains the most common function of PAM modules. Programmers being programmers, there are now PAM modules to do much more than authentication. A variety of security tasks can be done through modules, and there are utilities for session management.

Highlighted modules should be used in most systems that are connected to a network. is an easily underestimated module that allows the system administrator to adjust the user environment. checks passwords for strength and security.

Use in the password section of a PAM configuration file. The module uses the libcrack code to test whether the password is easily cracked, then runs additional tests against the old password and against system administrator determined parameters. relies on /usr/lib/cracklib_dict, and has only a password component.

As well as the libcrack tests, checks whether the new password is the old password with a change of case, whether it is a palindrome of the old password, whether it satisfies the difok argument, whether it passes the minimum length check, whether it's been recently used, and whether it's a simple rotation of the old password.

Useful arguments

difok = N
The number of characters in the new password which must not also be in the old password. The default is 10. If half the characters in the new password are new, the password passes this test.
minlen = N
Minimum length of the new password, plus one. Length credit is given for each different type of character in the new password (each case, symbols ("other") and digits). If using md5 passwords, a longer password is recommended.
dcredit, ucredit, lcredit and ocredit
The amount of length credit given for each type of character in the password (digits, each case, "other").

Example use

# /etc/pam.d/example

password    required    minlen=15 ocredit=2
password    required        use_authtok md5 allows you to set or unset environment variables using strings, existing variables, or PAM items.

The settings for this module are in /etc/security/pam_env.conf (though the argument conffile can override this). Syntax for this file is:


Comment on this articleWhat is your favorite thing about Pluggable Authentication Modules?
Post your comments

Previously in this series:

Introduction to PAM -- Pluggable Authentication Modules provide a solution to the difficulties of user authentication. Jennifer Vesperman introduces PAM and helps you get started.

The default settings are used if the override settings are not available. Environment variables can be referred to using ${variable}, and PAM items using @{variable}.

Valid PAM items for use with /etc/security/pam_env.conf are: PAM_USER, PAM_USER_PROMPT, PAM_TTY, PAM_RUSER, and PAM_RHOST. If is used on login, the ${USER} environment variable is not yet set. Use @{PAM_USER} instead.

The readenv argument toggles whether reads the environment file, /etc/environment, by default. The envfile argument allows you to use a different environment file. This file uses KEY=VALUE syntax to set the values of environment variables.

The module has only an auth component.

Set per-user environment variables

One use of is setting per-user environment variables. Setting $TMP and $TMPDIR variables for each user can provide security -- well-behaved programs will use the per-user temporary directories, which you can lock away from other users. ($TMP and $TMPDIR both refer to the temporary directories, the name of the variable was standardized late.)

Example use

# /etc/pam.d/login
# (This is a fairly minimal 'login' configuration)
auth      requisite
auth      requisite
auth      required
auth      required	nullok
account   required
session   required
password  required retry=3 minlen=6
password  required use_authtok nullok obscure

# /etc/security/pam_env.conf
# Set temp directories. 

# /etc/profile
# Create the temp directories if they don't exist.
# NOTE: this code doesn't test that they belong 
# to the user!
test -d $TMP || mkdir $TMP 
test -d $TMPDIR || mkdir $TMPDIR

User authentication

The most common modules provide some form of user authentication, or modify user authentication in some way.

This module enables FTP-style anonymous login. If the user name is "ftp" or "anonymous", it allows automatic access and parses the password as an email address for logging. It only has an auth component.

Parameters include users, which provides additional login names for anonymous login, and ignore, which ignores the email address/password. interfaces with Kerberos authentication. It has auth, session, and password components. It relies on Kerberos include files, and on libkrb, libdes, libcom_err, and libadm.

The auth component requests a ticket-granting ticket from the Kerberos server, uses it to attempt to retrieve a local host key, and verifies it with the local key file (if the file exists). It provides a ticket file for later use, and deletes that on logout.

The password component uses the old password to request a session key for the Kerberos password changer, and uses the key to send the new password.

The session component deletes the Kerberos ticket on logout. (This is redundant with the auth component.)

This module does standard Unix password authentication and session management, performing the same functions as the module described in Introduction to PAM. uses the password database library -- libpwdb -- instead of the traditional Unix password libraries.

The libpwdb library implements configurable authentication, using /etc/password, /etc/shadow, and network authentication tools like NIS and RADIUS. has all four components, and the same arguments as connects PAM to Radius authentication/accounting servers for accounting (but not authentication) purposes. It only has a session component. should be used as the last required session module for the application it authenticates. This module requires /etc/raddb/server and /etc/raddb/dictionary, and expects libpwdb.

Access control

The modules in this section limit, control or adjust access to the calling applications.

This module controls access by user name, host name, domain names, IP addresses, and terminal lines. It is configured in /etc/security/access.conf. This module only has an account component. It is recommended for use on NIS machines and other servers where accounts need to exist, but do not have login capability.

This module enables root to be locked out of any tty but the one in /etc/securetty -- usually console. The application using this module must correctly set the PAM item PAM_TTY. This module only has an auth component, and should be one of the required modules, before any sufficient modules. allows access restrictions by time. Restriction options include day of the week, time of day, user, service, and tty. Configure this module in /etc/security/time.conf. It only has an account component.

This module is intended for use with the su program. It restricts access to the superuser account to the wheel group, or to group ID "0" (if there is no wheel group). It only has an auth component. Wheel is the traditional name for the group authorized to su to root.


Use group [name] instead of wheel.
Return PAM_SUCCESS, which allows su without passwords, instead of PAM_IGNORE. This has obvious security implications.
Reverses the module's logic. Use this with the group argument to prohibit certain groups from using su.
Base the module's logic on the uid of a program, rather than of the user.

Session accessories

These are modules that don't affect security, but which make life easier or better for the user or the system administrator.

This module allows the administrator to set resource limits on users. It relies on libpwdb, and on kernel support for resource limits. It should be used as a required session module. is configured in /etc/security/limits.conf. The first entry which matches the user is the one which will apply to that user. The syntax is:

domain	type	item	value

Term expansion: provides the "you have new mail" service to the user. It has both session and auth components, and should be treated as an optional module. Arguments include dir=[directory] (for the mail directory), and quiet (only report if there is new mail, don't report the absence of mail or old mail).

This module creates home directories on the fly for authenticated users, and is particularly useful for batch addition of users. requires the arguments 'skel=[directory]', for a skeleton home directory, and 'umask=[octal mask]'.

Final words

Linux Network Administrator's Guide, 2nd EditionLinux Network Administrator's Guide, 2nd Edition
By Olaf Kirch & Terry Dawson
2nd Edition June 2000
1-56592-400-2, Order Number: 4002
503 pages, $39.95

PAM modules provide flexibility in authentication and session management. See the further reading section, or the PAM manuals on your system, for more information on the modules.

PAM is built into many Linux distributions, including Caldera 1.3, 2.2 and later; Debian 2.2 and later; Turbo Linux 3.6 and later; Red Hat 5.0 and later; and SuSE 6.2 (partial support). FreeBSD supports PAM from version 3.1.

If your system is one of the ones which has built in PAM, you are probably already using many PAM modules. Examine /etc/pam.d or /etc/pam.conf for details of what your system is already doing with PAM.

Further reading

Jennifer Vesperman is the author of Essential CVS. She writes for the O'Reilly Network, the Linux Documentation Project, and occasionally Linux.Com.

Return to the Linux DevCenter.

Copyright © 2009 O'Reilly Media, Inc.