DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Next Previous Contents

4. Generic optional arguments

Here we list the generic arguments that all modules can expect to be passed. They are not mandatory, and their absence should be accepted without comment by the module.

debug

Use the syslog(3) call to log debugging information to the system log files.

no_warn

Instruct module to not give warning messages to the application.

use_first_pass

The module should not prompt the user for a password. Instead, it should obtain the previously typed password (by a call to pam_get_item() for the PAM_AUTHTOK item), and use that. If that doesn't work, then the user will not be authenticated. (This option is intended for auth and passwd modules only).

try_first_pass

The module should attempt authentication with the previously typed password (by a call to pam_get_item() for the PAM_AUTHTOK item). If that doesn't work, then the user is prompted for a password. (This option is intended for auth modules only).

use_mapped_pass

WARNING: coding this functionality may cause the module writer to break local encryption laws. For example, in the U.S. there are restrictions on the export computer code that is capable of strong encryption. It has not been established whether this option is affected by this law, but one might reasonably assume that it does until told otherwise. For this reason, this option is not supported by any of the modules distributed with Linux-PAM.

The intended function of this argument, however, is that the module should take the existing authentication token from a previously invoked module and use it as a key to retrieve the authentication token for this module. For example, the module might create a strong hash of the PAM_AUTHTOK item (established by a previously executed module). Then, with logical-exclusive-or, use the result as a key to safely store/retrieve the authentication token for this module in/from a local file etc. .

expose_account

In general the leakage of some information about user accounts is not a secure policy for modules to adopt. Sometimes information such as users names or home directories, or preferred shell, can be used to attack a user's account. In some circumstances, however, this sort of information is not deemed a threat: displaying a user's full name when asking them for a password in a secured environment could also be called being 'friendly'. The expose_account argument is a standard module argument to encourage a module to be less discrete about account information as it is deemed appropriate by the local administrator.


Next Previous Contents