Applications need to check if the users are authorized. Instead of having this implemented in each application individually they can delegate it to PAM (Pluggable Authentication Modules). Applications that support PAM will find always the same interface and use the library.

This allows by just editing the pam configuration files introduce different ways to identify the user as finger print, memory stick, remote login with different encryption methods without the need of re-compiling/configuring the application using pam.


PAM applications

Since every application using pam has a configuration file in the directory /etc/pam.d ls /stc/pam.d list all applications using pam.


Some configuration files are used/included by other configuration files and are therefore not linked to a single application.

If an application does not find its matching file it uses the default file /etc/pam.d/other. This file should be present and deny every access.

To check if a program (application) support pam check if it uses the pam library that is used as interface to pam

ldd<name of the program> | grep


ldd /bin/login | grep => /lib64/ (0x00007f7752f88000)

PAM modules

Pam has modules for the authentication method. Documentation about those modules can be found under /usr/share/doc/pam-1.2.1-r2/modules. The modules itself are under /lib/security and as it can be observed there, the pam modules are shared object libraries. They have names as pam_<name>.so and some have even manual pages so man pam_<name>.so pops up a description.

To see what a module support, go to /lib/security and type:

nm --dynamic --defined-only pam_<name>.so

PAM configuration files

The /etc/pam.d files are structured as a spreadsheet having columns and rows.

The first column in the /etc/pam.d files contains what the application wants from pam. pam (or the pam modules) can support the following:

  1. auth (Example: Verify that a user has entered the correct password)

  2. account (Example: Check if the user is allowed to do this task)

  3. password (Example: Check if the password is not too simple)

  4. session (Example: Doing things before and after login as mounting or logging)

The next column is called the controlflag and defines how the rows (modules) are stacked together. It can be:


A failure will lead to failure but only after the remaining rows are processed.


The row must pass. It returns immediately when failed


If it passes PAM immediately passes without calling the next modules,

It is allowed to fail


Is allowed to fail except if it is the only one


Includes all lines of an other /etc/pam.d file


As include, but just for a group of lines

Additionally to the above controlflags there is an alternative syntax using a term in brackets [] where more detailed controlflags can be defined.

The next column is the module that is used followed by a column where options to the module can be passed. Common options might be: debug, use_mapped_pass and use_first_pass.

How it fits together

The files in /etc/pam.d hold the rules for the authentication and make use of the modules in /lib/security. The files in /etc/pam.d have a rule per line. To be more flexible different lines can be stacked together so they get sequentially read until the authentication shows the result pass or failed.

It is important to understand the different parties involved in PAM:

  1. Application making use of pam e.g. requests authentication and calls

  2. reads the pam configuration files /etc/pam.d setting up the rules for authentication

  3. starts the pam modules that are shared object files in /lib/security

PAM Examples


      auth       sufficient

Passes and returns if the the user is root. It does not fail if it is not root but continues with the following row.

auth include system-auth

It does not call an other pam module (so library) but processes the /etc/pam.d/system-auth pam config file.

Linurs Servernest startpage