Here we collect some pointers for the module writer to bear in mind when writing/developing a Linux-PAM compatible module.
Regarding the use of the conversation function, the module should reset the contents of the pointer that will return the applications response. This is a good idea since the application may fail to fill the pointer and the module should be in a position to notice!
To ensure that the authentication tokens are not left lying around the
items, PAM_AUTHTOK
and PAM_OLDAUTHTOK
, are not available to
the application: they are defined in
<security/pam_modules.h>
. This is ostensibly for
security reasons, but a maliciously programmed application will always
have access to all memory of the process, so it is only superficially
enforced. As a general rule the module should overwrite
authentication tokens as soon as they are no longer needed. Especially
before free()
'ing them. The Linux-PAM library is required to
do this when either of these authentication token items are (re)set.
Not to dwell too little on this concern; should the module store the
authentication tokens either as (automatic) function variables or
using pam_[gs]et_data()
the associated memory should be
over-written explicitly before it is released. In the case of the
latter storage mechanism, the associated cleanup()
function
should explicitly overwrite the *data
before free()
'ing it:
for example,
/*
* An example cleanup() function for releasing memory that was used to
* store a password.
*/
int cleanup(pam_handle_t *pamh, void *data, int error_status)
{
char *xx;
if ((xx = data)) {
while (*xx)
*xx++ = '\0';
free(data);
}
return PAM_SUCCESS;
}
syslog(3)
Only rarely should error information be directed to the user. Usually,
this is to be limited to ``sorry you cannot login now'' type
messages. Information concerning errors in the configuration file,
/etc/pam.conf
, or due some system failure encountered by the
module should be written to syslog(3)
with facility-type
LOG_AUTHPRIV
.
With a few exceptions, the level of logging is, at the discression of the module developer. Here is the recommended usage of different logging levels:
LOG_ERR
level. However, information regarding an unrecognized
argument, passed to a module from an entry in the
/etc/pam.conf
file, is required to be logged at the
LOG_ERR
level.
debug
argument to the
module in /etc/pam.conf
, should be logged at the
LOG_DEBUG
level.
LOG_ALERT
.
malloc()
failures should be logged at level LOG_CRIT
.
LOG_NOTICE
.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter