Each PAM-aware application or service has a file in the /etc/pam.d/ directory. Each file in this directory has the same name as the service to which it controls access.

The PAM-aware program is responsible for defining its service name and installing its own PAM configuration file in the /etc/pam.d/ directory. For example, the login program defines its service name as login and installs the /etc/pam.d/login PAM configuration file.

Four types of PAM module interface are currently available. Each of these corresponds to a different aspect of the authorization process:

In a PAM configuration file, the module interface is the first field defined. For example, a typical line in a configuration may look like this:

auth	required	pam_unix.so

This instructs PAM to use the pam_unix.so module's auth interface.

[root@MyServer ~]# cat /etc/pam.d/reboot
#%PAM-1.0
auth	sufficient	pam_rootok.so
auth	required	pam_console.so
#auth	include	system-auth
account	required	pam_permit.so

All PAM modules generate a success or failure result when called. Control flags tell PAM what do with the result. Modules can be stacked in a particular order, and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service.

There are four predefined control flags:

A newer control flag syntax that allows for more precise control is now available for PAM.

The pam.d man page, and the PAM documentation, located in the /usr/share/doc/pam-<version-number>/ directory, where <version-number> is the version number for PAM on your system, describe this newer syntax in detail.

The module name provides PAM with the name of the pluggable module containing the specified module interface. In older versions of Red Hat Enterprise Linux, the full path to the module was provided in the PAM configuration file. However, since the advent of multilib systems, which store 64-bit PAM modules in the /lib64/security/ directory, the directory name is omitted because the application is linked to the appropriate version of libpam, which can locate the correct version of the module.

PAM uses arguments to pass information to a pluggable module during authentication for some modules.

For example, the pam_userdb.so module uses information stored in a Berkeley DB file to authenticate the user. Berkeley DB is an open source database system embedded in many applications. The module takes a db argument so that Berkeley DB knows which database to use for the requested service.

The following is a typical pam_userdb.so line in a PAM configuration. The <path-to-file> is the full path to the Berkeley DB database file:

auth	required	pam_userdb.so db=<path-to-file>

Invalid arguments are generally ignored and do not otherwise affect the success or failure of the PAM module. Some modules, however, may fail on invalid arguments. Most modules report errors to the /var/log/secure file.

Before abandoning a console where a PAM timestamp is active, it is recommended that the timestamp file be destroyed. To do this from a graphical environment, click the authentication icon on the panel. This causes a dialog box to appear. Click the Forget Authorization button to destroy the active timestamp file.

[D]

Figure 42.8. Dismiss Authentication Dialog

You should be aware of the following with respect to the PAM timestamp file:

Refer to the pam_timestamp_check man page for more information about destroying the timestamp file using pam_timestamp_check.

The pam_timestamp.so module accepts several directives. The following are the two most commonly used options:

Refer to Section 42.4.8.1, “Installed Documentation” for more information about controlling the pam_timestamp.so module.

When a user logs in to a Red Hat Enterprise Linux system, the pam_console.so module is called by login or the graphical login programs, gdm, kdm, and xdm. If this user is the first user to log in at the physical console — referred to as the console user — the module grants the user ownership of a variety of devices normally owned by root. The console user owns these devices until the last local session for that user ends. After this user has logged out, ownership of the devices reverts back to the root user.

The devices affected include, but are not limited to, sound cards, diskette drives, and CD-ROM drives.

This facility allows a local user to manipulate these devices without obtaining root access, thus simplifying common tasks for the console user.

You can modify the list of devices controlled by pam_console.so by editing the following files:

You can change the permissions of different devices than those listed in the above files, or override the specified defaults. Rather than modify the 50-default.perms file, you should create a new file (for example, xx-name.perms) and enter the required modifications. The name of the new default file must begin with a number higher than 50 (for example, 51-default.perms). This will override the defaults in the 50-default.perms file.

<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 
<xconsole>=:0\.[0-9] :0

<console>=tty[0-9][0-9]* vc/[0-9][0-9]*

The console user also has access to certain programs configured for use in the /etc/security/console.apps/ directory.

This directory contains configuration files which enable the console user to run certain applications in /sbin and /usr/sbin.

These configuration files have the same name as the applications that they set up.

One notable group of applications that the console user has access to are three programs that shut down or reboot the system:

Because these are PAM-aware applications, they call the pam_console.so module as a requirement for use.

Refer to Section 42.4.8.1, “Installed Documentation” for more information.