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{[lowbar]}warn

Instruct module to not give warning messages to the application.

use{[lowbar]}first{[lowbar]}pass

The module should not prompt the user for a password. Instead, it should obtain the previously typed password (by a call to pam{[lowbar]}get{[lowbar]}item() for the PAM{[lowbar]}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{[lowbar]}first{[lowbar]}pass

The module should attempt authentication with the previously typed password (by a call to pam{[lowbar]}get{[lowbar]}item() for the PAM{[lowbar]}AUTHTOK item). If that doesn't work, then the user is prompted for a password. (This option is intended for auth modules only).

use{[lowbar]}mapped{[lowbar]}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{[lowbar]}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{[lowbar]}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{[lowbar]}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