(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:

PAM_DATA_REPLACE

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

PAM_DATA_SILENT

  Which indicates that the process would prefer to perform the `cleanup()` quietly. That is, discourages logging/messages to the user. It is generally used to indicate that the current closing of the library is in a fork(2)ed process, and that the parent will take care of cleaning up things that exist outside of the current process space (files etc.).

#### 2.1.1.2. RETURN VALUES

PAM_BUF_ERR

  Memory buffer error.

PAM_SUCCESS

  Data was successful stored.

PAM_SYSTEM_ERR

  A NULL pointer was submitted as PAM handle or the function was called by an application.

### 2.1.2. Get module internal data

    #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`;

#### 2.1.2.1. DESCRIPTION

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.

#### 2.1.2.2. RETURN VALUES

PAM_SUCCESS

  Data was successful retrieved.

PAM_SYSTEM_ERR

  A NULL pointer was submitted as PAM handle or the function was called by an application.

PAM_NO_MODULE_DATA

  No module specific data is present.

### 2.1.3. Setting PAM items

    #include <security/pam_modules.h>

`int pam_set_item(` | pamh, |
| item_type, |
| item`)`; |

`pam_handle_t *pamh`;
`int item_type`;
`const void *item`;

#### 2.1.3.1. DESCRIPTION

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:

PAM_SERVICE

  The service name (which identifies that PAM stack that the PAM functions will use to authenticate the program).

PAM_USER

  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.

PAM_USER_PROMPT

  The string used when prompting for a user's name. The default value for this string is a localized version of "login: ".

PAM_TTY

  The terminal name prefixed by `/dev/` for device files. In the past, graphical X-based applications used to store the $DISPLAY variable here, but with the introduction of PAM_XDISPLAY this usage is deprecated.

PAM_RUSER

  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.

PAM_RHOST

  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.

PAM_AUTHTOK

  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.

PAM_OLDAUTHTOK

  The old authentication token. This token should be ignored by all module functions except pam_sm_chauthtok(3).

PAM_CONV

  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:

PAM_FAIL_DELAY

  A function pointer to redirect centrally managed failure delays. See pam_fail_delay(3).

PAM_XDISPLAY

  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.

PAM_XAUTHDATA

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

PAM_AUTHTOK_TYPE

  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.

#### 2.1.3.2. RETURN VALUES

PAM_BAD_ITEM

  The application attempted to set an undefined or inaccessible item.

PAM_BUF_ERR

  Memory buffer error.

PAM_SUCCESS

  Data was successful updated.

PAM_SYSTEM_ERR

  The pam_handle_t passed as first argument was invalid.

### 2.1.4. Getting PAM items

    #include <security/pam_modules.h>

`int pam_get_item(` | pamh, |
| item_type, |
| item`)`; |

`const pam_handle_t *pamh`;
`int item_type`;
`const void **item`;

#### 2.1.4.1. DESCRIPTION

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:

PAM_SERVICE

  The service name (which identifies that PAM stack that the PAM functions will use to authenticate the program).

PAM_USER

  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.

PAM_USER_PROMPT

  The string used when prompting for a user's name. The default value for this string is a localized version of "login: ".

PAM_TTY

  The terminal name prefixed by `/dev/` for device files. In the past, graphical X-based applications used to store the $DISPLAY variable here, but with the introduction of PAM_XDISPLAY this usage is deprecated.

PAM_RUSER

  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.

PAM_RHOST

  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.

PAM_AUTHTOK

  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.

PAM_OLDAUTHTOK

  The old authentication token. This token should be ignored by all module functions except pam_sm_chauthtok(3).

PAM_CONV

  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:

PAM_FAIL_DELAY

  A function pointer to redirect centrally managed failure delays. See pam_fail_delay(3).

PAM_XDISPLAY

  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.

PAM_XAUTHDATA

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

PAM_AUTHTOK_TYPE

  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.

#### 2.1.4.2. RETURN VALUES

PAM_BAD_ITEM

  The application attempted to set an undefined or inaccessible item.

PAM_BUF_ERR

  Memory buffer error.

PAM_PERM_DENIED

  The value of item was NULL.

PAM_SUCCESS

  Data was successful updated.

PAM_SYSTEM_ERR

  The pam_handle_t passed as first argument was invalid.

### 2.1.5. Get user name

    #include <security/pam_modules.h>

`int pam_get_user(` | pamh, |
| user, |
| prompt`)`; |

`const pam_handle_t *pamh`;
`const char **user`;
`const char *prompt`;

#### 2.1.5.1. DESCRIPTION

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.

#### 2.1.5.2. RETURN VALUES

PAM_SUCCESS

  User name was successful retrieved.

PAM_SYSTEM_ERR

  A NULL pointer was submitted.

PAM_CONV_ERR

  The conversation method supplied by the application failed to obtain the username.

PAM_BUF_ERR

  Memory buffer error.

PAM_ABORT

  Error resuming an old conversation.

PAM_CONV_AGAIN

  The conversation method supplied by the application is waiting for an event.

### 2.1.6. The conversation function

    #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;
    };

#### 2.1.6.1. DESCRIPTION

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:

PAM_PROMPT_ECHO_OFF

  Obtain a string without echoing any text.

PAM_PROMPT_ECHO_ON

  Obtain a string whilst echoing text.

PAM_ERROR_MSG

  Display an error message.

PAM_TEXT_INFO

  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])

#### 2.1.6.2. RETURN VALUES

PAM_BUF_ERR

  Memory buffer error.

PAM_CONV_ERR

  Conversation failure. The application should not set *resp.

PAM_SUCCESS

  Success.

### 2.1.7. Set or change PAM environment variable

    #include <security/pam_appl.h>

`int pam_putenv(` | pamh, |
| name_value`)`; |

`pam_handle_t *pamh`;
`const char *name_value`;

#### 2.1.7.1. DESCRIPTION

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:

NAME=value of variable

  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.

NAME=

  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.

NAME

  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.

#### 2.1.7.2. RETURN VALUES

PAM_PERM_DENIED

  Argument name_value given is a NULL pointer.

PAM_BAD_ITEM

  Variable requested (for deletion) is not currently set.

PAM_ABORT

  The pamh handle is corrupt.

PAM_BUF_ERR

  Memory buffer error.

PAM_SUCCESS

  The environment variable was successfully updated.

### 2.1.8. Get a PAM environment variable

    #include <security/pam_appl.h>

`const char *pam_getenv(` | pamh, |
| name`)`; |

`pam_handle_t *pamh`;
`const char *name`;

#### 2.1.8.1. DESCRIPTION

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.

#### 2.1.8.2. RETURN VALUES

The `pam_getenv` function returns NULL on failure.

### 2.1.9. Getting the PAM environment

    #include <security/pam_appl.h>

`char **pam_getenvlist(` | pamh`)`; |

`pam_handle_t *pamh`;

#### 2.1.9.1. DESCRIPTION

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.

#### 2.1.9.2. RETURN VALUES

The `pam_getenvlist` function returns NULL on failure.

Prev | Up | Next
Chapter 2. What can be expected by the module | Home | 2.2. Other functions provided by `libpam`