PAM module-arguments

Overview #

Pluggable Authentication Modules utilizes arguments to pass information to a pluggable module during authentication for a particular PAM Service Types. These arguments allow the PAM configuration files for particular programs to use a common PAM module but in different ways.

The PAM module-arguments are a space separated list of tokens that can be used to modify the specific behavior of the given PAM.

Such arguments will be documented for each individual module. Note, if you wish to include spaces in an argument, you should surround that argument with square brackets.

 squid auth required pam_mysql.so user=passwd_query passwd=mada db=eminence [query=select user_name from internet_service where user_name='%u' and password=PASSWORD('%p') and service='web_proxy']

When using this convention, you can include '[' characters inside the string, and if you wish to include a ']' character inside the string that will survive the argument parsing, you should use '\]'.

In other words:

    [..[..\]..]    -->   ..[..]..
Any line in (one of) the configuration file(s), that is not formatted correctly, will generally tend (erring on the side of caution) to make the authentication process fail.

A corresponding error is written to the system log files with a call to syslog.

Some Module Arguments#

Although module arguments behavior are module specific, some can be generalized.


The argument shadow tells the module to create shadow passwords when updating a user's password.


The argument nullok instructs the module to allow the a null or empty value. As an example, nullok instructs the pam_unix.so module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock.

nonull #

Null values are not allowed.


The final argument on this line, use_authtok, provides a good example of the importance of order when stacking PAM modules. This argument tells the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass the pam_cracklib.so test for secure passwords before being accepted.

Like try_first_pass, but *fail* if the new PAM_AUTHTOK has not been previously set (intended for stacking password modules only).

debug #

Log more debugging info.

audit #

Like debug, but also logs unknown usernames.

use_first_pass #

Do not prompt the user for passwords; take them from PAM_ items instead.

try_first_pass #

Try to get the password from a previous PAM module; fall back to prompting the user.

not_set_pass #

Do not make passwords used by this module available to other modules.


Do not insert ~1-second delays on authentication failure.


likeauth, tells the module return the same value for credential (password) changes as for authentication, ensuring equivalent security in both cases

More Information#

There might be more information for this subject on one of the following: