|
|
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.