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

Introduction to PAM

by Jennifer Vesperman

User authentication has always been a problem. Build it into a program, and it's hard to change. Leave it out, and you have no security at all. Now there's an alternative: PAM, or Pluggable Authentication Modules.

PAM provides an interface that programs can use to connect to whatever authentication methods are desired. Authentication can be as trivial as the user typing "hello world", as complex as biometrics, or as prosaic as passwords.

PAM isn't the only way to do this. GSS-API, defined in RFCs 1508 and 1509, is a similar authentication interface protocol. Kerberos, SSh, and Heimdal are different, and focus on securing the authentication process itself rather than linking applications to authentication 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.

Configuring PAM

Originally, the PAM configuration file was /etc/pam.conf. More recent versions of PAM use a separate file for each PAM-using program, in the directory /etc/pam.d, though some will check both /etc/pam.conf and /etc/pam.d when attempting to authenticate for a program. /etc/pam.d is recommended -- having separate files for each program prevents misconfigurations for one program from affecting others.

Defaults: The 'other' file

The default case of a PAM configuration is /etc/pam.d/other (or the lines for the other program in /etc/pam.conf). For a secure installation, configure other to use the and modules to block access to unconfigured programs. If you want access rather than security, use instead of To write to syslog, use Using in the other configuration file will identify programs which expect, but don't have, PAM configurations.

Configuration lines

In each file in /etc/pam.d, the configuration lines are:

module-type   control-flag   module-path   arguments

Module types:

Control flags:

PAM modules can be stacked -- there can be any number of modules of the same module type for a single application. The application is not told of the individual success or failure of any module, only of the success or failure of the stack. The control flags determine how each module affects the success or failure of the stack. Modules in the stack are executed in the order they are listed in the configuration file.

There are two formats for the control flag. The simpler form uses four keywords: required, requisite, sufficient, and optional. The complex form gives a great deal more control to the system administrator, at the cost of requiring the system administrator to determine an action for each of up to 30 return values. This article covers the simple form.

Module Path:

The path name of the module.


Comment on this articlePAM seems like an ideal solution for user authentication extensibility, but how does it fare when put to use?
Post your comments

Any arguments to the module. This is module-specific, but most modules should recognize the following arguments:

Configuration examples

# /etc/pam.d/login
# Mimics traditional Unix login without any frills.
account  required       /usr/lib/security/
auth     requisite      /usr/lib/security/
auth     required       /usr/lib/security/
session  required       /usr/lib/security/

# /etc/pam.d/passwd
# Slight variations on the traditional Unix password-changer.
# The module '' is useful for enforcing password security.
password required  /usr/lib/security/ nullok md5 remember=5

# /etc/pam.d/other
# Prevents the use of programs which are unconfigured.
account  required       /usr/lib/security/
auth     required       /usr/lib/security/
auth     required       /usr/lib/security/
password required       /usr/lib/security/
password required       /usr/lib/security/
session  required       /usr/lib/security/

Basic PAM modules

This module provides traditional Unix authentication, password management, and user account setup. It uses standard system calls to retrieve and set password and account information, and relies on /etc/shadow and /etc/passwd.

Establishes the validity of the user's account and password and may offer advice on changing the user's password, or force a password change. The actions this module performs are controlled by the /etc/passwd and /etc/shadow files.

Arguments: audit, debug.

This component of the module checks the user's password against the password databases. Configuration for this component is done in /etc/nsswitch.conf. An additional binary, unix_chkpwd, is used to allow the component to read protected databases without requiring the whole module to be setuid root.

Arguments: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.

This component changes the user's password. The module can be stacked with this component to check password security.

Arguments: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok, and use_first_pass.

This component logs the user name and session type to syslog, at the start and end of the user's session. There are no arguments to this component.


This module logs information about an authentication or password change attempt to syslog.

This module has no arguments, and only auth and password components.

This module blocks access to the application. As an auth or an account component, it prevents users from authenticating or starting their account. As a password component, it prevents users from changing their password. As a session component, it can be stacked with something like to display a message and prevent the user from starting a shell.

This module has no arguments, and all four components. The inverse module is

Provides standard Unix nologin authentication. If the file /etc/nologin exists, only root is allowed access and all users see the contents of /etc/nologin. The module succeeds silently if /etc/nologin is not present.

This module has no arguments, and only an auth component. It should be included in the configurations for all login methods as a required module, listed before any sufficient modules.

Testing a program for PAM compatibility

Documentation for PAM-enabled applications should include the name of the PAM configuration file. If it doesn't, use the name of the program (or the authentication component of the program).

To test whether a program is PAM enabled, create a configuration file for that program in /etc/pam.d, and add these lines:

auth    required
auth    required

If the program is PAM enabled, these lines permit access to all users and put a warning in syslog whenever you run the program. Run the program, try to log in, and check syslog -- if there's a warning there, the program works with PAM.

Caveats and gotchas

Related Reading

Building Internet Firewalls, 2nd Ed. Building Internet Firewalls, 2nd Ed.
By Elizabeth D. Zwicky, Simon Cooper & D. Brent Chapman
Table of Contents
Sample Chapter
Full Description
Read Online -- Safari

Don't delete /etc/pam.d/* or /etc/pam.conf unless you enjoy being locked out of your system. To fix this, reboot into single user mode and restore the files.

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.