Home > Articles > Programming > Android

PAM Configuration

There are two different PAM configuration compile-time options. The first causes PAM either to use a single /etc/pam.conf file as its configuration file or to look for a collection of configuration files in /etc/pam.d, but not both. The second option uses both mechanisms and entries in /etc/pam.d directory override those in /etc/pam.conf. The first option is recommended and reflects the implementation used by the Red Hat 5.2/6.0 distributions.

There is little difference between using a single /etc/pam.conf and a collection of files in /etc/pam.d. Essentially, if you are using /etc/pam.conf, each entry in /etc/pam.conf contains a leading service-type field that specifies the PAM-aware application to which this entry pertains. If you use /etc/ pam.d, you will find a file in that directory whose name matches a PAM-aware application. Consequently, the service-type field is dropped from each of these files. We will discuss the configuration options under the assumption of the use of /etc/pam.d. For those of you who use /etc/pam.conf, just add the service type to the entries described here.

Let's begin by taking a look at the contents of /etc/pam.d, shown in Example 5-1. This effectively lists the PAM-aware applications that ship with the Red Hat 5.2 distribution (6.0 is similar). Each of the files listed has a PAM-aware application associated with it. In all of these configuration files, lines beginning with # are comment lines and are ignored by PAM.

Example 5-1 Contents of /etc/pam.d

#ls /etc/pam.d
chfn    linuxconf-pair  ppp   su
chsh    login      rexec  vlock
ftp    mcserv      rlogin xdm
imap    other      rsh   xlock
linuxconf passwd      samba

Each of the PAM configuration files contains the entry types shown in Example 5-2. The module-type field specifies the type of PAM module. Currently there are four module types, auth, account, session, and password. They are described in Table 5.1.

Example 5-2 PAM Configuration File Entry Fields 

module-type control-flag module-path arguments

The control-flag field specifies the action to be taken depending on the result of the PAM module. More than one PAM module may be specified for a given application (this is called stacking). The control-flag also determines the relative importance of modules in a stack. As we will see, stack order and control-flags are very significant. The four possible values for this field are required, requisite, optional, and sufficient. They are summarized in Table 5.2.

The module-path field indicates the absolute pathname location of the PAM module. Red Hat 5.2/6.0 places all PAM modules in /lib/security. (Table 5.15 on page 110 provides an overview of many of the available PAM modules, both from the Red Hat distribution and the public domain.)

Table 5.1 PAM Module Types

Module Type

Description

auth

The auth module instructs the application to prompt the user for identification such as a password. It may set credentials and may also grant privileges.

Account

The account module checks on various aspects of the user's account such as password aging, limit access to particular time periods or from particular locations. It also may be used to limit system access based on system resources.

Session

The session module type is used to provide functions before and after session establishment. This includes setting up an environment, logging, etc.

Password

The password module type is normally stacked with an auth module. It is responsible for updating the user authentication token, often a password.

Table 5.2 PAM Control Flags

Control Flag

Description

Required

This module must return success for the service to be granted. If this module is one in a series of stacked modules, all other modules are still executed. The application will not be informed as to which module or modules failed.

Requisite

As above, except that failure here terminates execution of all modules and immediately returns a failure status to the application.

Optional

As the name implies, this module is not required. If it is the only module, however, its return status to an application may cause failure.

Sufficient

If this module succeeds, all remaining modules in the stack are ignored and success is returned to the application. In particular, if the module succeeds, this means that no subsequent modules in the stack are executed, regardless of the control flags associated with the subsequent modules. If this module fails it does not necessarily cause failure of the stack, unless it is the only module in the stack.

The arguments field is used for specifying flags or options that are passed to the module. Specifying arguments is optional. There are certain general arguments available for most modules which are listed in Table 5.3. Other arguments are available on a per-module basis and will be discussed appropriately with each module.

In summary, each file in /etc/pam.d is associated with the service or application after which the file is named and contains a list of records, each of which contains a module type, control flag, module name and location, and optional arguments. If the modules are of the same type, they are considered to be stacked and will be executed in the order in which they appear, unless control flags terminate execution earlier. The entire stack, not just one module, controls behavior for the given service and module type. Arguments are optionally used to further control the behavior of the module.

Table 5.3 PAM Standard Arguments

Standard Arguments

Description

Debug

Generates additional output to the syslog * utility. Most PAM modules support this argument. Its exact definition depends on the module to which this argument is supplied.

no_warn

Do not pass warning messages to the application.

use_first_pass

This module will use the password from the previous module. If it fails, no attempt is made to obtain another entry from the user. This argument is intended for auth and password modules only.

try_first_pass

As above, except that, if the password fails, it will prompt the user for another entry. This argument is intended for auth and password modules only.

Now let's see how this mechanism is actually implemented.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.