First, we cover what the module should expect from the
Linux-PAM library and a
Linux-PAM aware application.
Essentially this is the libpam.* library.
#include <security/pam_modules.h>
int pam_set_data( | pamh, | |
| module_data_name, | ||
| data, | ||
(*cleanup)(pam_handle_t *pamh, void *data, int error_status)); |
pam_handle_t *pamh;const char *module_data_name;void *data;void (*cleanup)(pam_handle_t *pamh, void *data, int error_status);
The pam_set_data function associates a pointer
to an object with the (hopefully) unique string
module_data_name in the PAM context specified
by the pamh argument.
PAM modules may be dynamically loadable objects. In general such files
should not contain static variables. This function
and its counterpart
pam_get_data(3),
provide a mechanism for a module to associate some data with
the handle pamh. Typically a module will call the
pam_set_data function to register some data
under a (hopefully) unique module_data_name.
The data is available for use by other modules too but
not by an application. Since this functions
stores only a pointer to the data, the module
should not modify or free the content of it.
The function cleanup() is associated with the
data and, if non-NULL, it is called when this
data is over-written or following a call to
pam_end(3).
The error_status argument is used to indicate to the module the sort of action it is to take in cleaning this data item. As an example, Kerberos creates a ticket file during the authentication phase, this file might be associated with a data item. When pam_end(3) is called by the module, the error_status carries the return value of the pam_authenticate(3) or other libpam function as appropriate. Based on this value the Kerberos module may choose to delete the ticket file (authentication failure) or leave it in place.
The error_status may have been logically OR'd with either of the following two values:
When a data item is being replaced (through a second call to
pam_set_data) this mask is used.
Otherwise, the call is assumed to be from
pam_end(3).
Which indicates that the process would prefer to perform the
cleanup() quietly. That is, discourages
logging/messages to the user.
#include <security/pam_modules.h>
int pam_get_data( | pamh, | |
| module_data_name, | ||
data); |
const pam_handle_t *pamh;const char *module_data_name;const void **data;This function together with the pam_set_data(3) function is useful to manage module-specific data meaningful only to the calling PAM module.
The pam_get_data function looks up the
object associated with the (hopefully) unique string
module_data_name in the PAM context
specified by the pamh argument.
A successful call to
pam_get_data will result in
data pointing to the object. Note,
this data is not a copy and should be
treated as constant by the module.
#include <security/pam_modules.h>
int pam_set_item( | pamh, | |
| item_type, | ||
item); |
pam_handle_t *pamh;int item_type;const void *item;
The pam_set_item function allows applications
and PAM service modules to access and to update PAM information
of item_type. For this a copy
of the object pointed to by the item argument
is created. The following item_types are
supported:
The service name (which identifies that PAM stack that the PAM functions will use to authenticate the program).
The username of the entity under whose identity service will be given. That is, following authentication, PAM_USER identifies the local entity that gets to use the service. Note, this value can be mapped from something (eg., "anonymous") to something else (eg. "guest119") by any module in the PAM stack. As such an application should consult the value of PAM_USER after each call to a PAM function.
The string used when prompting for a user's name. The default value for this string is a localized version of "login: ".
The terminal name: prefixed by /dev/ if
it is a device file; for graphical, X-based, applications the
value for this item should be the
$DISPLAY variable.
The requesting user name: local name for a locally requesting user or a remote user name for a remote requesting user.
Generally an application or module will attempt to supply the value that is most strongly authenticated (a local account before a remote one. The level of trust in this value is embodied in the actual authentication stack associated with the application, so it is ultimately at the discretion of the system administrator.
PAM_RUSER@PAM_RHOST should always identify the requesting user. In some cases, PAM_RUSER may be NULL. In such situations, it is unclear who the requesting entity is.
The requesting hostname (the hostname of the machine from which the PAM_RUSER entity is requesting service). That is PAM_RUSER@PAM_RHOST does identify the requesting user. In some applications, PAM_RHOST may be NULL. In such situations, it is unclear where the authentication request is originating from.
The authentication token (often a password). This token should be ignored by all module functions besides pam_sm_authenticate(3) and pam_sm_chauthtok(3). In the former function it is used to pass the most recent authentication token from one stacked module to another. In the latter function the token is used for another purpose. It contains the currently active authentication token.
The old authentication token. This token should be ignored by all module functions except pam_sm_chauthtok(3).
The pam_conv structure. See pam_conv(3).
The following additional items are specific to Linux-PAM and should not be used in portable applications:
A function pointer to redirect centrally managed failure delays. See pam_fail_delay(3).
The name of the X display. For graphical, X-based applications the value for this item should be the $DISPLAY variable. This value may be used independently of PAM_TTY for passing the name of the display.
A pointer to a structure containing the X authentication data required to make a connection to the display specified by PAM_XDISPLAY, if such information is necessary. See pam_xauth_data(3).
The default action is for the module to use the following prompts when requesting passwords: "New UNIX password: " and "Retype UNIX password: ". The example word UNIX can be replaced with this item, by default it is empty. This item is used by pam_get_authtok(3).
For all item_types, other than PAM_CONV and
PAM_FAIL_DELAY, item is a pointer to a <NUL>
terminated character string. In the case of PAM_CONV,
item points to an initialized
pam_conv structure. In the case of
PAM_FAIL_DELAY, item is a function pointer:
void (*delay_fn)(int retval, unsigned usec_delay, void *appdata_ptr)
Both, PAM_AUTHTOK and PAM_OLDAUTHTOK, will be reset before returning to the application. Which means an application is not able to access the authentication tokens.
#include <security/pam_modules.h>
int pam_get_item( | pamh, | |
| item_type, | ||
item); |
const pam_handle_t *pamh;int item_type;const void **item;
The pam_get_item function allows applications
and PAM service modules to access and retrieve PAM information
of item_type. Upon successful return,
item contains a pointer to the value of the
corresponding item. Note, this is a pointer to the
actual data and should
not be free()'ed or
over-written! The following values are supported for
item_type:
The service name (which identifies that PAM stack that the PAM functions will use to authenticate the program).
The username of the entity under whose identity service will be given. That is, following authentication, PAM_USER identifies the local entity that gets to use the service. Note, this value can be mapped from something (eg., "anonymous") to something else (eg. "guest119") by any module in the PAM stack. As such an application should consult the value of PAM_USER after each call to a PAM function.
The string used when prompting for a user's name. The default value for this string is a localized version of "login: ".
The terminal name: prefixed by /dev/ if
it is a device file; for graphical, X-based, applications the
value for this item should be the
$DISPLAY variable.
The requesting user name: local name for a locally requesting user or a remote user name for a remote requesting user.
Generally an application or module will attempt to supply the value that is most strongly authenticated (a local account before a remote one. The level of trust in this value is embodied in the actual authentication stack associated with the application, so it is ultimately at the discretion of the system administrator.
PAM_RUSER@PAM_RHOST should always identify the requesting user. In some cases, PAM_RUSER may be NULL. In such situations, it is unclear who the requesting entity is.
The requesting hostname (the hostname of the machine from which the PAM_RUSER entity is requesting service). That is PAM_RUSER@PAM_RHOST does identify the requesting user. In some applications, PAM_RHOST may be NULL. In such situations, it is unclear where the authentication request is originating from.
The authentication token (often a password). This token should be ignored by all module functions besides pam_sm_authenticate(3) and pam_sm_chauthtok(3). In the former function it is used to pass the most recent authentication token from one stacked module to another. In the latter function the token is used for another purpose. It contains the currently active authentication token.
The old authentication token. This token should be ignored by all module functions except pam_sm_chauthtok(3).
The pam_conv structure. See pam_conv(3).
The following additional items are specific to Linux-PAM and should not be used in portable applications:
A function pointer to redirect centrally managed failure delays. See pam_fail_delay(3).
The name of the X display. For graphical, X-based applications the value for this item should be the $DISPLAY variable. This value may be used independently of PAM_TTY for passing the name of the display.
A pointer to a structure containing the X authentication data required to make a connection to the display specified by PAM_XDISPLAY, if such information is necessary. See pam_xauth_data(3).
The default action is for the module to use the following prompts when requesting passwords: "New UNIX password: " and "Retype UNIX password: ". The example word UNIX can be replaced with this item, by default it is empty. This item is used by pam_get_authtok(3).
If a service module wishes to obtain the name of the user, it should not use this function, but instead perform a call to pam_get_user(3).
Only a service module is privileged to read the authentication tokens, PAM_AUTHTOK and PAM_OLDAUTHTOK.
#include <security/pam_modules.h>
int pam_get_user( | pamh, | |
| user, | ||
prompt); |
const pam_handle_t *pamh;const char **user;const char *prompt;
The pam_get_user function returns the
name of the user specified by
pam_start(3). If no user was specified it returns what
pam_get_item (pamh, PAM_USER, ... ); would
have returned. If this is NULL it obtains the username via the
pam_conv(3) mechanism, it prompts the user with the first
non-NULL string in the following list:
The prompt argument passed to the function.
What is returned by pam_get_item (pamh, PAM_USER_PROMPT, ... );
The default prompt: "login: "
By whatever means the username is obtained, a pointer to it is returned as the contents of *user. Note, this memory should not be free()'d or modified by the module.
This function sets the PAM_USER item associated with the pam_set_item(3) and pam_get_item(3) functions.
User name was successful retrieved.
A NULL pointer was submitted.
The conversation method supplied by the application failed to obtain the username.
Memory buffer error.
Error resuming an old conversation.
The conversation method supplied by the application is waiting for an event.
#include <security/pam_appl.h>
struct pam_message {
int msg_style;
const char *msg;
};
struct pam_response {
char *resp;
int resp_retcode;
};
struct pam_conv {
int (*conv)(int num_msg, const struct pam_message **msg,
struct pam_response **resp, void *appdata_ptr);
void *appdata_ptr;
};
The PAM library uses an application-defined callback to allow a direct communication between a loaded module and the application. This callback is specified by the struct pam_conv passed to pam_start(3) at the start of the transaction.
When a module calls the referenced conv() function, the argument appdata_ptr is set to the second element of this structure.
The other arguments of a call to conv() concern the information exchanged by module and application. That is to say, num_msg holds the length of the array of pointers, msg. After a successful return, the pointer resp points to an array of pam_response structures, holding the application supplied text. The resp_retcode member of this struct is unused and should be set to zero. It is the caller's responsibility to release both, this array and the responses themselves, using free(3). Note, *resp is a struct pam_response array and not an array of pointers.
The number of responses is always equal to the num_msg conversation function argument. This does require that the response array is free(3)'d after every call to the conversation function. The index of the responses corresponds directly to the prompt index in the pam_message array.
On failure, the conversation function should release any resources it has allocated, and return one of the predefined PAM error codes.
Each message can have one of four types, specified by the msg_style member of struct pam_message:
Obtain a string without echoing any text.
Obtain a string whilst echoing text.
Display an error message.
Display some text.
The point of having an array of messages is that it becomes possible to pass a number of things to the application in a single call from the module. It can also be convenient for the application that related things come at once: a windows based application can then present a single form with many messages/prompts on at once.
In passing, it is worth noting that there is a discrepancy between the way Linux-PAM handles the const struct pam_message **msg conversation function argument and the way that Solaris' PAM (and derivatives, known to include HP/UX, are there others?) does. Linux-PAM interprets the msg argument as entirely equivalent to the following prototype const struct pam_message *msg[] (which, in spirit, is consistent with the commonly used prototypes for argv argument to the familiar main() function: char **argv; and char *argv[]). Said another way Linux-PAM interprets the msg argument as a pointer to an array of num_msg read only 'struct pam_message' pointers. Solaris' PAM implementation interprets this argument as a pointer to a pointer to an array of num_msg pam_message structures. Fortunately, perhaps, for most module/application developers when num_msg has a value of one these two definitions are entirely equivalent. Unfortunately, casually raising this number to two has led to unanticipated compatibility problems.
For what its worth the two known module writer work-arounds for trying to maintain source level compatibility with both PAM implementations are:
never call the conversation function with num_msg greater than one.
set up msg as doubly referenced so both types of conversation function can find the messages. That is, make
msg[n] = & (( *msg )[n])
#include <security/pam_appl.h>
int pam_putenv( | pamh, | |
name_value); |
pam_handle_t *pamh;const char *name_value;
The pam_putenv function is used to
add or change the value of PAM environment variables as
associated with the pamh handle.
The pamh argument is an authentication handle obtained by a prior call to pam_start(). The name_value argument is a single NUL terminated string of one of the following forms:
In this case the environment variable of the given NAME is set to the indicated value: value of variable. If this variable is already known, it is overwritten. Otherwise it is added to the PAM environment.
This function sets the variable to an empty value. It is listed separately to indicate that this is the correct way to achieve such a setting.
Without an '=' the pam_putenv() function
will delete the
corresponding variable from the PAM environment.
pam_putenv() operates on a copy of
name_value, which means in contrast to
putenv(3), the application is responsible for freeing the data.
#include <security/pam_appl.h>
const char *pam_getenv( | pamh, | |
name); |
pam_handle_t *pamh;const char *name;
The pam_getenv function searches the
PAM environment list as associated with the handle
pamh for an item that matches the string
pointed to by name and returns a pointer
to the value of the environment variable. The application is
not allowed to free the data.
#include <security/pam_appl.h>
char **pam_getenvlist( | pamh); |
pam_handle_t *pamh;
The pam_getenvlist function returns a complete
copy of the PAM environment as associated with the handle
pamh. The PAM environment variables
represent the contents of the regular environment variables of the
authenticated user when service is granted.
The format of the memory is a malloc()'d array of char pointers, the last element of which is set to NULL. Each of the non-NULL entries in this array point to a NUL terminated and malloc()'d char string of the form: "name=value".
It should be noted that this memory will never be free()'d by
libpam. Once obtained by a call to
pam_getenvlist, it is the responsibility of
the calling application to free() this memory.
It is by design, and not a coincidence, that the format and contents of the returned array matches that required for the third argument of the execle(3) function call.