TThhee LLiinnuuxx--PPAAMM MMoodduullee WWrriitteerrss'' GGuuiiddee
******** AAnnddrreeww GG.. MMoorrggaann ********
<_m_o_r_g_a_n_@_k_e_r_n_e_l_._o_r_g>
******** TThhoorrsstteenn KKuukkuukk ********
<_k_u_k_u_k_@_t_h_k_u_k_u_k_._d_e>
Version 1.1.2, 31. August 2010
AAbbssttrraacctt
This manual documents what a programmer needs to know in order to write a
module that conforms to the LLiinnuuxx--PPAAMM standard.It also discusses some security
issues from the point of view of the module programmer.
===============================================================================
  _1_._ _I_n_t_r_o_d_u_c_t_i_o_n
        _1_._1_._ _D_e_s_c_r_i_p_t_i_o_n
        _1_._2_._ _S_y_n_o_p_s_i_s
  _2_._ _W_h_a_t_ _c_a_n_ _b_e_ _e_x_p_e_c_t_e_d_ _b_y_ _t_h_e_ _m_o_d_u_l_e
        _2_._1_._ _G_e_t_t_i_n_g_ _a_n_d_ _s_e_t_t_i_n_g_ _PP_AA_MM____II_TT_EE_MM_s_ _a_n_d_ _dd_aa_tt_aa
              _2_._1_._1_._ _S_e_t_ _m_o_d_u_l_e_ _i_n_t_e_r_n_a_l_ _d_a_t_a
              _2_._1_._2_._ _G_e_t_ _m_o_d_u_l_e_ _i_n_t_e_r_n_a_l_ _d_a_t_a
              _2_._1_._3_._ _S_e_t_t_i_n_g_ _P_A_M_ _i_t_e_m_s
              _2_._1_._4_._ _G_e_t_t_i_n_g_ _P_A_M_ _i_t_e_m_s
              _2_._1_._5_._ _G_e_t_ _u_s_e_r_ _n_a_m_e
              _2_._1_._6_._ _T_h_e_ _c_o_n_v_e_r_s_a_t_i_o_n_ _f_u_n_c_t_i_o_n
              _2_._1_._7_._ _S_e_t_ _o_r_ _c_h_a_n_g_e_ _P_A_M_ _e_n_v_i_r_o_n_m_e_n_t_ _v_a_r_i_a_b_l_e
              _2_._1_._8_._ _G_e_t_ _a_ _P_A_M_ _e_n_v_i_r_o_n_m_e_n_t_ _v_a_r_i_a_b_l_e
              _2_._1_._9_._ _G_e_t_t_i_n_g_ _t_h_e_ _P_A_M_ _e_n_v_i_r_o_n_m_e_n_t
        _2_._2_._ _O_t_h_e_r_ _f_u_n_c_t_i_o_n_s_ _p_r_o_v_i_d_e_d_ _b_y_ _l_i_b_p_a_m
              _2_._2_._1_._ _S_t_r_i_n_g_s_ _d_e_s_c_r_i_b_i_n_g_ _P_A_M_ _e_r_r_o_r_ _c_o_d_e_s
              _2_._2_._2_._ _R_e_q_u_e_s_t_ _a_ _d_e_l_a_y_ _o_n_ _f_a_i_l_u_r_e
  _3_._ _W_h_a_t_ _i_s_ _e_x_p_e_c_t_e_d_ _o_f_ _a_ _m_o_d_u_l_e
        _3_._1_._ _O_v_e_r_v_i_e_w
              _3_._1_._1_._ _F_u_n_c_t_i_o_n_a_l_ _i_n_d_e_p_e_n_d_e_n_c_e
              _3_._1_._2_._ _M_i_n_i_m_i_z_i_n_g_ _a_d_m_i_n_i_s_t_r_a_t_i_o_n_ _p_r_o_b_l_e_m_s
              _3_._1_._3_._ _A_r_g_u_m_e_n_t_s_ _s_u_p_p_l_i_e_d_ _t_o_ _t_h_e_ _m_o_d_u_l_e
        _3_._2_._ _A_u_t_h_e_n_t_i_c_a_t_i_o_n_ _m_a_n_a_g_e_m_e_n_t
              _3_._2_._1_._ _S_e_r_v_i_c_e_ _f_u_n_c_t_i_o_n_ _f_o_r_ _u_s_e_r_ _a_u_t_h_e_n_t_i_c_a_t_i_o_n
              _3_._2_._2_._ _S_e_r_v_i_c_e_ _f_u_n_c_t_i_o_n_ _t_o_ _a_l_t_e_r_ _c_r_e_d_e_n_t_i_a_l_s
        _3_._3_._ _A_c_c_o_u_n_t_ _m_a_n_a_g_e_m_e_n_t
              _3_._3_._1_._ _S_e_r_v_i_c_e_ _f_u_n_c_t_i_o_n_ _f_o_r_ _a_c_c_o_u_n_t_ _m_a_n_a_g_e_m_e_n_t
        _3_._4_._ _S_e_s_s_i_o_n_ _m_a_n_a_g_e_m_e_n_t
              _3_._4_._1_._ _S_e_r_v_i_c_e_ _f_u_n_c_t_i_o_n_ _t_o_ _s_t_a_r_t_ _s_e_s_s_i_o_n_ _m_a_n_a_g_e_m_e_n_t
              _3_._4_._2_._ _S_e_r_v_i_c_e_ _f_u_n_c_t_i_o_n_ _t_o_ _t_e_r_m_i_n_a_t_e_ _s_e_s_s_i_o_n_ _m_a_n_a_g_e_m_e_n_t
        _3_._5_._ _A_u_t_h_e_n_t_i_c_a_t_i_o_n_ _t_o_k_e_n_ _m_a_n_a_g_e_m_e_n_t
              _3_._5_._1_._ _S_e_r_v_i_c_e_ _f_u_n_c_t_i_o_n_ _t_o_ _a_l_t_e_r_ _a_u_t_h_e_n_t_i_c_a_t_i_o_n_ _t_o_k_e_n
  _4_._ _G_e_n_e_r_i_c_ _o_p_t_i_o_n_a_l_ _a_r_g_u_m_e_n_t_s
  _5_._ _P_r_o_g_r_a_m_m_i_n_g_ _n_o_t_e_s
        _5_._1_._ _S_e_c_u_r_i_t_y_ _i_s_s_u_e_s_ _f_o_r_ _m_o_d_u_l_e_ _c_r_e_a_t_i_o_n
              _5_._1_._1_._ _S_u_f_f_i_c_i_e_n_t_ _r_e_s_o_u_r_c_e_s
              _5_._1_._2_._ _W_h_o__s_ _w_h_o_?
              _5_._1_._3_._ _U_s_i_n_g_ _t_h_e_ _c_o_n_v_e_r_s_a_t_i_o_n_ _f_u_n_c_t_i_o_n
              _5_._1_._4_._ _A_u_t_h_e_n_t_i_c_a_t_i_o_n_ _t_o_k_e_n_s
        _5_._2_._ _U_s_e_ _o_f_ _s_y_s_l_o_g_(_3_)
        _5_._3_._ _M_o_d_u_l_e_s_ _t_h_a_t_ _r_e_q_u_i_r_e_ _s_y_s_t_e_m_ _l_i_b_r_a_r_i_e_s
  _6_._ _A_n_ _e_x_a_m_p_l_e_ _m_o_d_u_l_e
  _7_._ _S_e_e_ _a_l_s_o
  _8_._ _A_u_t_h_o_r_/_a_c_k_n_o_w_l_e_d_g_m_e_n_t_s
  _9_._ _C_o_p_y_r_i_g_h_t_ _i_n_f_o_r_m_a_t_i_o_n_ _f_o_r_ _t_h_i_s_ _d_o_c_u_m_e_n_t
CChhaapptteerr 11.. IInnttrroodduuccttiioonn
11..11.. DDeessccrriippttiioonn
LLiinnuuxx--PPAAMM (Pluggable Authentication Modules for Linux) is a library that
enables the local system administrator to choose how individual applications
authenticate users. For an overview of the LLiinnuuxx--PPAAMM library see the LLiinnuuxx--PPAAMM
SSyysstteemm AAddmmiinniissttrraattoorrss'' GGuuiiddee.
A LLiinnuuxx--PPAAMM module is a single executable binary file that can be loaded by the
LLiinnuuxx--PPAAMM interface library. This PAM library is configured locally with a
system file, /etc/pam.conf, to authenticate a user request via the locally
available authentication modules. The modules themselves will usually be
located in the directory /lib/security (or /lib64/security, depending on the
architecture) and take the form of dynamically loadable object files (see
dlopen(3). Alternatively, the modules can be statically linked into the LLiinnuuxx--
PPAAMM library; this is mostly to allow LLiinnuuxx--PPAAMM to be used on platforms without
dynamic linking available, but this is a ddeepprreeccaatteedd functionality. It is the
LLiinnuuxx--PPAAMM interface that is called by an application and it is the
responsibility of the library to locate, load and call the appropriate
functions in a LLiinnuuxx--PPAAMM-module.
Except for the immediate purpose of interacting with the user (entering a
password etc..) the module should never call the application directly. This
exception requires a "conversation mechanism" which is documented below.
11..22.. SSyynnooppssiiss
#include <security/pam_modules.h>

gcc -fPIC -c pam_module.c
gcc -shared -o pam_module.so pam_module.o -lpam
CChhaapptteerr 22.. WWhhaatt ccaann bbee eexxppeecctteedd bbyy tthhee mmoodduullee
Here we list the interface that the conventions that all LLiinnuuxx--PPAAMM modules must
adhere to.
22..11..  GGeettttiinngg aanndd sseettttiinngg PPAAMM__IITTEEMMss aanndd ddaattaa
First, we cover what the module should expect from the LLiinnuuxx--PPAAMM library and a
LLiinnuuxx--PPAAMM aware application. Essentially this is the libpam.* library.
22..11..11.. SSeett mmoodduullee iinntteerrnnaall ddaattaa
#include <security/pam_modules.h>
int ppaamm__sseett__ddaattaa( 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);
 
22..11..11..11.. DDEESSCCRRIIPPTTIIOONN
The pam_set_data function associates a pointer to an object with the
(hopefully) unique string mmoodduullee__ddaattaa__nnaammee in the PAM context specified by the
ppaammhh argument.
PAM modules may be dynamically loadable objects. In general such files should
not contain ssttaattiicc variables. This function and its counterpart pam_get_data
(3), provide a mechanism for a module to associate some data with the handle
ppaammhh. Typically a module will call the pam_set_data function to register some
data under a (hopefully) unique mmoodduullee__ddaattaa__nnaammee. The data is available for use
by other modules too but nnoott by an application. Since this functions stores
only a pointer to the ddaattaa, the module should not modify or free the content of
it.
The function cleanup() is associated with the ddaattaa and, if non-NULL, it is
called when this data is over-written or following a call to pam_end(3).
The eerrrroorr__ssttaattuuss 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 eerrrroorr__ssttaattuuss carries
the return value of the pam_authenticate(3) or other lliibbppaamm function as
appropriate. Based on this value the Kerberos module may choose to delete the
ticket file (aauutthheennttiiccaattiioonn ffaaiilluurree) or leave it in place.
The eerrrroorr__ssttaattuuss 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.
22..11..11..22.. RREETTUURRNN VVAALLUUEESS
  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2..11..22.. GGeett mmoodduullee iinntteerrnnaall ddaattaa
#include <security/pam_modules.h>
int ppaamm__ggeett__ddaattaa( pamh,              
                  module_data_name,  
                  data);             
const pam_handle_t *pamh;
const char *module_data_name;
const void **data;
 
22..11..22..11.. DDEESSCCRRIIPPTTIIOONN
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 mmoodduullee__ddaattaa__nnaammee in the PAM context specified by the ppaammhh
argument. A successful call to pam_get_data will result in ddaattaa pointing to the
object. Note, this data is nnoott a copy and should be treated as ccoonnssttaanntt by the
module.
22..11..22..22.. RREETTUURRNN VVAALLUUEESS
  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
      Module data not found or there is an entry, but it has the value NULL.
22..11..33.. SSeettttiinngg PPAAMM iitteemmss
#include <security/pam_modules.h>
int ppaamm__sseett__iitteemm( pamh,       
                  item_type,  
                  item);      
pam_handle_t *pamh;
int item_type;
const void *item;
 
22..11..33..11.. DDEESSCCRRIIPPTTIIOONN
The pam_set_item function allows applications and PAM service modules to access
and to update PAM informations of iitteemm__ttyyppee. For this a copy of the object
pointed to by the iitteemm argument is created. The following iitteemm__ttyyppees 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, PPAAMM__UUSSEERR 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 PPAAMM__UUSSEERR 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/ if it is a device file; for
      graphical, X-based, applications the value for this item should be the
      $$DDIISSPPLLAAYY variable.
  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.
      PPAAMM__RRUUSSEERR@@PPAAMM__RRHHOOSSTT should always identify the requesting user. In some
      cases, PPAAMM__RRUUSSEERR 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
      PPAAMM__RRUUSSEERR entity is requesting service). That is PPAAMM__RRUUSSEERR@@PPAAMM__RRHHOOSSTT does
      identify the requesting user. In some applications, PPAAMM__RRHHOOSSTT 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 $$DDIISSPPLLAAYY variable. This value may be used
      independently of PPAAMM__TTTTYY 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 PPAAMM__XXDDIISSPPLLAAYY, 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 UUNNIIXX can be replaced with this item, by default it is
      empty. This item is used by pam_get_authtok(3).
For all iitteemm__ttyyppees, other than PAM_CONV and PAM_FAIL_DELAY, iitteemm is a pointer
to a <NUL> terminated character string. In the case of PAM_CONV, iitteemm points to
an initialized ppaamm__ccoonnvv structure. In the case of PAM_FAIL_DELAY, iitteemm is a
function pointer: void (*delay_fn)(int retval, unsigned usec_delay, void
*appdata_ptr)
Both, PAM_AUTHTOK and PAM_OLDAUTHTOK, will be reseted before returning to the
application. Which means an application is not able to access the
authentication tokens.
22..11..33..22.. RREETTUURRNN VVAALLUUEESS
  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 ppaamm__hhaannddllee__tt passed as first argument was invalid.
22..11..44.. GGeettttiinngg PPAAMM iitteemmss
#include <security/pam_modules.h>
int ppaamm__ggeett__iitteemm( pamh,       
                  item_type,  
                  item);      
const pam_handle_t *pamh;
int item_type;
const void **item;
 
22..11..44..11.. DDEESSCCRRIIPPTTIIOONN
The pam_get_item function allows applications and PAM service modules to access
and retrieve PAM informations of iitteemm__ttyyppee. Upon successful return, iitteemm
contains a pointer to the value of the corresponding item. Note, this is a
pointer to the aaccttuuaall data and should nnoott be ffrreeee(())'ed or over-written! The
following values are supported for iitteemm__ttyyppee:
  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, PPAAMM__UUSSEERR 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 PPAAMM__UUSSEERR 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/ if it is a device file; for
      graphical, X-based, applications the value for this item should be the
      $$DDIISSPPLLAAYY variable.
  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.
      PPAAMM__RRUUSSEERR@@PPAAMM__RRHHOOSSTT should always identify the requesting user. In some
      cases, PPAAMM__RRUUSSEERR 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
      PPAAMM__RRUUSSEERR entity is requesting service). That is PPAAMM__RRUUSSEERR@@PPAAMM__RRHHOOSSTT does
      identify the requesting user. In some applications, PPAAMM__RRHHOOSSTT 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 $$DDIISSPPLLAAYY variable. This value may be used
      independently of PPAAMM__TTTTYY 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 PPAAMM__XXDDIISSPPLLAAYY, 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 UUNNIIXX 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2..11..44..22.. RREETTUURRNN VVAALLUUEESS
  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 iitteemm was NULL.
  PAM_SUCCESS
      Data was successful updated.
  PAM_SYSTEM_ERR
      The ppaamm__hhaannddllee__tt passed as first argument was invalid.
22..11..55.. GGeett uusseerr nnaammee
#include <security/pam_modules.h>
int ppaamm__ggeett__uusseerr( pamh,     
                  user,     
                  prompt);  
const pam_handle_t *pamh;
const char **user;
const char *prompt;
 
22..11..55..11.. DDEESSCCRRIIPPTTIIOONN
The pam_get_user function returns the name of the user specified by pam_start
(3). If no user was specified it 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 pprroommpptt 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 **uusseerr. Note, this memory should nnoott be ffrreeee(())'d or mmooddiiffiieedd by the
module.
This function sets the PPAAMM__UUSSEERR item associated with the pam_set_item(3) and
pam_get_item(3) functions.
22..11..55..22.. RREETTUURRNN VVAALLUUEESS
  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.
22..11..66.. TThhee ccoonnvveerrssaattiioonn ffuunnccttiioonn
#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2..11..66..11.. DDEESSCCRRIIPPTTIIOONN
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 ssttrruucctt ppaamm__ccoonnvv passed to pam_start(3) at the start of the
transaction.
When a module calls the referenced conv() function, the argument aappppddaattaa__ppttrr 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, nnuumm__mmssgg holds the length of the array
of pointers, mmssgg. After a successful return, the pointer rreesspp points to an
array of pam_response structures, holding the application supplied text. The
rreesspp__rreettccooddee 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, **rreesspp is a ssttrruucctt ppaamm__rreessppoonnssee array and not
an array of pointers.
The number of responses is always equal to the nnuumm__mmssgg 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 mmssgg__ssttyyllee member of
ssttrruucctt ppaamm__mmeessssaaggee:
  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 descrepency between the way
Linux-PAM handles the const struct pam_message **msg conversation function
argument from the way that Solaris' PAM (and derivitives, 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2..11..66..22.. RREETTUURRNN VVAALLUUEESS
  PAM_BUF_ERR
      Memory buffer error.
  PAM_CONV_ERR
      Conversation failure. The application should not set **rreesspp.
  PAM_SUCCESS
      Success.
22..11..77.. SSeett oorr cchhaannggee PPAAMM eennvviirroonnmmeenntt vvaarriiaabbllee
#include <security/pam_appl.h>
int ppaamm__ppuutteennvv( pamh,         
                name_value);  
pam_handle_t *pamh;
const char *name_value;
 
22..11..77..11.. DDEESSCCRRIIPPTTIIOONN
The pam_putenv function is used to add or change the value of PAM environment
variables as associated with the ppaammhh handle.
The ppaammhh argument is an authentication handle obtained by a prior call to
pam_start(). The nnaammee__vvaalluuee 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: vvaalluuee ooff vvaarriiaabbllee. 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 nnaammee__vvaalluuee, which means in contrast to
putenv(3), the application is responsible to free the data.
22..11..77..22.. RREETTUURRNN VVAALLUUEESS
  PAM_PERM_DENIED
      Argument nnaammee__vvaalluuee given is a NULL pointer.
  PAM_BAD_ITEM
      Variable requested (for deletion) is not currently set.
  PAM_ABORT
      The ppaammhh handle is corrupt.
  PAM_BUF_ERR
      Memory buffer error.
  PAM_SUCCESS
      The environment variable was successfully updated.
22..11..88.. GGeett aa PPAAMM eennvviirroonnmmeenntt vvaarriiaabbllee
#include <security/pam_appl.h>
const char *ppaamm__ggeetteennvv( pamh,   
                        name);  
pam_handle_t *pamh;
const char *name;
 
22..11..88..11.. DDEESSCCRRIIPPTTIIOONN
The pam_getenv function searches the PAM environment list as associated with
the handle ppaammhh for an item that matches the string pointed to by nnaammee and
returns a pointer to the value of the environment variable. The application is
not allowed to free the data.
22..11..88..22.. RREETTUURRNN VVAALLUUEESS
The pam_getenv function returns NULL on failure.
22..11..99.. GGeettttiinngg tthhee PPAAMM eennvviirroonnmmeenntt
#include <security/pam_appl.h>
char **ppaamm__ggeetteennvvlliisstt( pamh);  
pam_handle_t *pamh;
 
22..11..99..11.. DDEESSCCRRIIPPTTIIOONN
The pam_getenvlist function returns a complete copy of the PAM environment as
associated with the handle ppaammhh. 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: "nnaammee==vvaalluuee".
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2..11..99..22.. RREETTUURRNN VVAALLUUEESS
The pam_getenvlist function returns NULL on failure.
22..22..  OOtthheerr ffuunnccttiioonnss pprroovviiddeedd bbyy lliibbppaamm
22..22..11.. SSttrriinnggss ddeessccrriibbiinngg PPAAMM eerrrroorr ccooddeess
#include <security/pam_appl.h>
const char *ppaamm__ssttrreerrrroorr( pamh,     
                          errnum);  
pam_handle_t *pamh;
int errnum;
 
22..22..11..11.. DDEESSCCRRIIPPTTIIOONN
The pam_strerror function returns a pointer to a string describing the error
code passed in the argument eerrrrnnuumm, possibly using the LC_MESSAGES part of the
current locale to select the appropriate language. This string must not be
modified by the application. No library function will modify this string.
22..22..11..22.. RREETTUURRNN VVAALLUUEESS
This function returns always a pointer to a string.
22..22..22.. RReeqquueesstt aa ddeellaayy oonn ffaaiilluurree
#include <security/pam_appl.h>
int ppaamm__ffaaiill__ddeellaayy( pamh,   
                    usec);  
pam_handle_t *pamh;
unsigned int usec;
 
22..22..22..11.. DDEESSCCRRIIPPTTIIOONN
The pam_fail_delay function provides a mechanism by which an application or
module can suggest a minimum delay of uusseecc micro-seconds. The function keeps a
record of the longest time requested with this function. Should
pam_authenticate(3) fail, the failing return to the application is delayed by
an amount of time randomly distributed (by up to 50%) about this longest value.
Independent of success, the delay time is reset to its zero default value when
the PAM service module returns control to the application. The delay occurs
aafftteerr all authentication modules have been called, but bbeeffoorree control is
returned to the service application.
When using this function the programmer should check if it is available with:
#ifdef HAVE_PAM_FAIL_DELAY
    ....
#endif /* HAVE_PAM_FAIL_DELAY */
For applications written with a single thread that are event driven in nature,
generating this delay may be undesirable. Instead, the application may want to
register the delay in some other way. For example, in a single threaded server
that serves multiple authentication requests from a single event loop, the
application might want to simply mark a given connection as blocked until an
application timer expires. For this reason the delay function can be changed
with the PPAAMM__FFAAIILL__DDEELLAAYY item. It can be queried and set with pam_get_item(3)
and pam_set_item (3) respectively. The value used to set it should be a
function pointer of the following prototype:
void (*delay_fn)(int retval, unsigned usec_delay, void *appdata_ptr);
The arguments being the rreettvvaall return code of the module stack, the uusseecc__ddeellaayy
micro-second delay that libpam is requesting and the aappppddaattaa__ppttrr that the
application has associated with the current ppaammhh. This last value was set by
the application when it called pam_start(3) or explicitly with pam_set_item(3).
Note, if PAM_FAIL_DELAY item is unset (or set to NULL), then no delay will be
performed.
22..22..22..22.. RREETTUURRNN VVAALLUUEESS
  PAM_SUCCESS
      Delay was successful adjusted.
  PAM_SYSTEM_ERR
      A NULL pointer was submitted as PAM handle.
CChhaapptteerr 33.. WWhhaatt iiss eexxppeecctteedd ooff aa mmoodduullee
The module must supply a sub-set of the six functions listed below. Together
they define the function of a LLiinnuuxx--PPAAMM mmoodduullee. Module developers are strongly
urged to read the comments on security that follow this list.
33..11.. OOvveerrvviieeww
The six module functions are grouped into four independent management groups.
These groups are as follows: aauutthheennttiiccaattiioonn, aaccccoouunntt, sseessssiioonn and ppaasssswwoorrdd. To
be properly defined, a module must define all functions within at least one of
these groups. A single module may contain the necessary functions for aallll four
groups.
33..11..11.. FFuunnccttiioonnaall iinnddeeppeennddeennccee
The independence of the four groups of service a module can offer means that
the module should allow for the possibility that any one of these four services
may legitimately be called in any order. Thus, the module writer should
consider the appropriateness of performing a service without the prior success
of some other part of the module.
As an informative example, consider the possibility that an application applies
to change a user's authentication token, without having first requested that
LLiinnuuxx--PPAAMM authenticate the user. In some cases this may be deemed appropriate:
when rroooott wants to change the authentication token of some lesser user. In
other cases it may not be appropriate: when jjooee maliciously wants to reset
aalliiccee's password; or when anyone other than the user themself wishes to reset
their KKEERRBBEERROOSS authentication token. A policy for this action should be defined
by any reasonable authentication scheme, the module writer should consider this
when implementing a given module.
33..11..22.. MMiinniimmiizziinngg aaddmmiinniissttrraattiioonn pprroobblleemmss
To avoid system administration problems and the poor construction of a /etc/
pam.conf file, the module developer may define all six of the following
functions. For those functions that would not be called, the module should
return PAM_SERVICE_ERR and write an appropriate message to the system log. When
this action is deemed inappropriate, the function would simply return
PAM_IGNORE.
33..11..33.. AArrgguummeennttss ssuupppplliieedd ttoo tthhee mmoodduullee
The ffllaaggss argument of each of the following functions can be logically OR'd
with PPAAMM__SSIILLEENNTT, which is used to inform the module to not pass any tteexxtt
(errors or warnings) application.
The aarrggcc and aarrggvv arguments are taken from the line appropriate to this module-
--that is, with the sseerrvviiccee__nnaammee matching that of the application---in the
configuration file (see the LLiinnuuxx--PPAAMM System Administrators' Guide). Together
these two parameters provide the number of arguments and an array of pointers
to the individual argument tokens. This will be familiar to C programmers as
the ubiquitous method of passing command arguments to the function main().
Note, however, that the first argument (aarrggvv[[00]]) is a true argument and nnoott the
name of the module.
33..22.. AAuutthheennttiiccaattiioonn mmaannaaggeemmeenntt
To be correctly initialized, PPAAMM__SSMM__AAUUTTHH must be ##ddeeffiinnee'd prior to including
<security/pam_modules.h>. This will ensure that the prototypes for static
modules are properly declared.
33..22..11.. SSeerrvviiccee ffuunnccttiioonn ffoorr uusseerr aauutthheennttiiccaattiioonn
#define PAM_SM_AUTH
#include <security/pam_modules.h>
int ppaamm__ssmm__aauutthheennttiiccaattee( pamh,   
                         flags,  
                         argc,   
                         argv);  
pam_handle_t *pamh;
int flags;
int argc;
const char **argv;
 
33..22..11..11.. DDEESSCCRRIIPPTTIIOONN
The pam_sm_authenticate function is the service module's implementation of the
pam_authenticate(3) interface.
This function performs the task of authenticating the user.
Valid flags, which may be logically OR'd with PPAAMM__SSIILLEENNTT, are:
  PAM_SILENT
      Do not emit any messages.
  PAM_DISALLOW_NULL_AUTHTOK
      Return PPAAMM__AAUUTTHH__EERRRR if the database of authentication tokens for this
      authentication mechanism has a NNUULLLL entry for the user. Without this
      flag, such a NNUULLLL token will lead to a success without the user being
      prompted.
33..22..11..22.. RREETTUURRNN VVAALLUUEESS
  PAM_AUTH_ERR
      Authentication failure.
  PAM_CRED_INSUFFICIENT
      For some reason the application does not have sufficient credentials to
      authenticate the user.
  PAM_AUTHINFO_UNAVAIL
      The modules were not able to access the authentication information. This
      might be due to a network or hardware failure etc.
  PAM_SUCCESS
      The authentication token was successfully updated.
  PAM_USER_UNKNOWN
      The supplied username is not known to the authentication service.
  PAM_MAXTRIES
      One or more of the authentication modules has reached its limit of tries
      authenticating the user. Do not try again.
33..22..22.. SSeerrvviiccee ffuunnccttiioonn ttoo aalltteerr ccrreeddeennttiiaallss
#define PAM_SM_AUTH
#include <security/pam_modules.h>
int ppaamm__ssmm__sseettccrreedd( pamh,   
                    flags,  
                    argc,   
                    argv);  
pam_handle_t *pamh;
int flags;
int argc;
const char **argv;
 
33..22..22..11.. DDEESSCCRRIIPPTTIIOONN
The pam_sm_setcred function is the service module's implementation of the
pam_setcred(3) interface.
This function performs the task of altering the credentials of the user with
respect to the corresponding authorization scheme. Generally, an authentication
module may have access to more information about a user than their
authentication token. This function is used to make such information available
to the application. It should only be called aafftteerr the user has been
authenticated but before a session has been established.
Valid flags, which may be logically OR'd with PPAAMM__SSIILLEENNTT, are:
  PAM_SILENT
      Do not emit any messages.
  PAM_ESTABLISH_CRED
      Initialize the credentials for the user.
  PAM_DELETE_CRED
      Delete the credentials associated with the authentication service.
  PAM_REINITIALIZE_CRED
      Reinitialize the user credentials.
  PAM_REFRESH_CRED
      Extend the lifetime of the user credentials.
The way the aauutthh stack is navigated in order to evaluate the pam_setcred()
function call, independent of the pam_sm_setcred() return codes, is exactly the
same way that it was navigated when evaluating the pam_authenticate() library
call. Typically, if a stack entry was ignored in evaluating pam_authenticate(),
it will be ignored when libpam evaluates the pam_setcred() function call.
Otherwise, the return codes from each module specific pam_sm_setcred() call are
treated as rreeqquuiirreedd.
33..22..22..22.. RREETTUURRNN VVAALLUUEESS
  PAM_CRED_UNAVAIL
      This module cannot retrieve the user's credentials.
  PAM_CRED_EXPIRED
      The user's credentials have expired.
  PAM_CRED_ERR
      This module was unable to set the credentials of the user.
  PAM_SUCCESS
      The user credential was successfully set.
  PAM_USER_UNKNOWN
      The user is not known to this authentication module.
These, non-PPAAMM__SSUUCCCCEESSSS, return values will typically lead to the credential
stack ffaaiilliinngg. The first such error will dominate in the return value of
pam_setcred().
33..33.. AAccccoouunntt mmaannaaggeemmeenntt
To be correctly initialized, PPAAMM__SSMM__AACCCCOOUUNNTT must be ##ddeeffiinnee'd prior to
including <security/pam_modules.h>. This will ensure that the prototypes for
static modules are properly declared.
33..33..11.. SSeerrvviiccee ffuunnccttiioonn ffoorr aaccccoouunntt mmaannaaggeemmeenntt
#define PAM_SM_ACCOUNT
#include <security/pam_modules.h>
int ppaamm__ssmm__aacccctt__mmggmmtt( pamh,   
                      flags,  
                      argc,   
                      argv);  
pam_handle_t *pamh;
int flags;
int argc;
const char **argv;
 
33..33..11..11.. DDEESSCCRRIIPPTTIIOONN
The pam_sm_acct_mgmt function is the service module's implementation of the
pam_acct_mgmt(3) interface.
This function performs the task of establishing whether the user is permitted
to gain access at this time. It should be understood that the user has
previously been validated by an authentication module. This function checks for
other things. Such things might be: the time of day or the date, the terminal
line, remote hostname, etc. This function may also determine things like the
expiration on passwords, and respond that the user change it before continuing.
Valid flags, which may be logically OR'd with PPAAMM__SSIILLEENNTT, are:
  PAM_SILENT
      Do not emit any messages.
  PAM_DISALLOW_NULL_AUTHTOK
      Return PPAAMM__AAUUTTHH__EERRRR if the database of authentication tokens for this
      authentication mechanism has a NNUULLLL entry for the user.
33..33..11..22.. RREETTUURRNN VVAALLUUEESS
  PAM_ACCT_EXPIRED
      User account has expired.
  PAM_AUTH_ERR
      Authentication failure.
  PAM_NEW_AUTHTOK_REQD
      The user's authentication token has expired. Before calling this function
      again the application will arrange for a new one to be given. This will
      likely result in a call to pam_sm_chauthtok().
  PAM_PERM_DENIED
      Permission denied.
  PAM_SUCCESS
      The authentication token was successfully updated.
  PAM_USER_UNKNOWN
      User unknown to password service.
33..44.. SSeessssiioonn mmaannaaggeemmeenntt
To be correctly initialized, PPAAMM__SSMM__SSEESSSSIIOONN must be ##ddeeffiinnee'd prior to
including <security/pam_modules.h>. This will ensure that the prototypes for
static modules are properly declared.
33..44..11.. SSeerrvviiccee ffuunnccttiioonn ttoo ssttaarrtt sseessssiioonn mmaannaaggeemmeenntt
#define PAM_SM_SESSION
#include <security/pam_modules.h>
int ppaamm__ssmm__ooppeenn__sseessssiioonn( pamh,   
                         flags,  
                         argc,   
                         argv);  
pam_handle_t *pamh;
int flags;
int argc;
const char **argv;
 
33..44..11..11.. DDEESSCCRRIIPPTTIIOONN
The pam_sm_open_session function is the service module's implementation of the
pam_open_session(3) interface.
This function is called to commence a session. The only valid value for flags
is zero or:
  PAM_SILENT
      Do not emit any messages.
33..44..11..22.. RREETTUURRNN VVAALLUUEESS
  PAM_SESSION_ERR
      Cannot make/remove an entry for the specified session.
  PAM_SUCCESS
      The session was successfully started.
33..44..22.. SSeerrvviiccee ffuunnccttiioonn ttoo tteerrmmiinnaattee sseessssiioonn mmaannaaggeemmeenntt
#define PAM_SM_SESSION
#include <security/pam_modules.h>
int ppaamm__ssmm__cclloossee__sseessssiioonn( pamh,   
                          flags,  
                          argc,   
                          argv);  
pam_handle_t *pamh;
int flags;
int argc;
const char **argv;
 
33..44..22..11.. DDEESSCCRRIIPPTTIIOONN
The pam_sm_close_session function is the service module's implementation of the
pam_close_session(3) interface.
This function is called to terminate a session. The only valid value for flags
is zero or:
  PAM_SILENT
      Do not emit any messages.
33..44..22..22.. RREETTUURRNN VVAALLUUEESS
  PAM_SESSION_ERR
      Cannot make/remove an entry for the specified session.
  PAM_SUCCESS
      The session was successfully terminated.
33..55.. AAuutthheennttiiccaattiioonn ttookkeenn mmaannaaggeemmeenntt
To be correctly initialized, PPAAMM__SSMM__PPAASSSSWWOORRDD must be ##ddeeffiinnee'd prior to
including <security/pam_modules.h>. This will ensure that the prototypes for
static modules are properly declared.
33..55..11.. SSeerrvviiccee ffuunnccttiioonn ttoo aalltteerr aauutthheennttiiccaattiioonn ttookkeenn
#define PAM_SM_PASSWORD
#include <security/pam_modules.h>
int ppaamm__ssmm__cchhaauutthhttookk( pamh,   
                      flags,  
                      argc,   
                      argv);  
pam_handle_t *pamh;
int flags;
int argc;
const char **argv;
 
33..55..11..11.. DDEESSCCRRIIPPTTIIOONN
The pam_sm_chauthtok function is the service module's implementation of the
pam_chauthtok(3) interface.
This function is used to (re-)set the authentication token of the user.
Valid flags, which may be logically OR'd with PPAAMM__SSIILLEENNTT, are:
  PAM_SILENT
      Do not emit any messages.
  PAM_CHANGE_EXPIRED_AUTHTOK
      This argument indicates to the module that the user's authentication
      token (password) should only be changed if it has expired. This flag is
      optional and mmuusstt be combined with one of the following two flags. Note,
      however, the following two options are mmuuttuuaallllyy eexxcclluussiivvee.
  PAM_PRELIM_CHECK
      This indicates that the modules are being probed as to their ready status
      for altering the user's authentication token. If the module requires
      access to another system over some network it should attempt to verify it
      can connect to this system on receiving this flag. If a module cannot
      establish it is ready to update the user's authentication token it should
      return PPAAMM__TTRRYY__AAGGAAIINN, this information will be passed back to the
      application.
      If the control value ssuuffffiicciieenntt is used in the password stack, the
      PPAAMM__PPRREELLIIMM__CCHHEECCKK section of the modules following that control value is
      not always executed.
  PAM_UPDATE_AUTHTOK
      This informs the module that this is the call it should change the
      authorization tokens. If the flag is logically OR'd with
      PPAAMM__CCHHAANNGGEE__EEXXPPIIRREEDD__AAUUTTHHTTOOKK, the token is only changed if it has actually
      expired.
The PAM library calls this function twice in succession. The first time with
PPAAMM__PPRREELLIIMM__CCHHEECCKK and then, if the module does not return PPAAMM__TTRRYY__AAGGAAIINN,
subsequently with PPAAMM__UUPPDDAATTEE__AAUUTTHHTTOOKK. It is only on the second call that the
authorization token is (possibly) changed.
33..55..11..22.. RREETTUURRNN VVAALLUUEESS
  PAM_AUTHTOK_ERR
      The module was unable to obtain the new authentication token.
  PAM_AUTHTOK_RECOVERY_ERR
      The module was unable to obtain the old authentication token.
  PAM_AUTHTOK_LOCK_BUSY
      Cannot change the authentication token since it is currently locked.
  PAM_AUTHTOK_DISABLE_AGING
      Authentication token aging has been disabled.
  PAM_PERM_DENIED
      Permission denied.
  PAM_TRY_AGAIN
      Preliminary check was unsuccessful. Signals an immediate return to the
      application is desired.
  PAM_SUCCESS
      The authentication token was successfully updated.
  PAM_USER_UNKNOWN
      User unknown to password service.
CChhaapptteerr 44.. GGeenneerriicc ooppttiioonnaall aarrgguummeennttss
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 pam_syslog(3) call to log debugging information to the system log
      files.
  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
      PPAAMM__AAUUTTHHTTOOKK item), and use that. If that doesn't work, then the user will
      not be authenticated. (This option is intended for aauutthh and ppaasssswwdd
      modules only).
CChhaapptteerr 55.. PPrrooggrraammmmiinngg nnootteess
Here we collect some pointers for the module writer to bear in mind when
writing/developing a LLiinnuuxx--PPAAMM compatible module.
55..11.. SSeeccuurriittyy iissssuueess ffoorr mmoodduullee ccrreeaattiioonn
55..11..11.. SSuuffffiicciieenntt rreessoouurrcceess
Care should be taken to ensure that the proper execution of a module is not
compromised by a lack of system resources. If a module is unable to open
sufficient files to perform its task, it should fail gracefully, or request
additional resources. Specifically, the quantities manipulated by the setrlimit
(2) family of commands should be taken into consideration.
55..11..22.. WWhhooss wwhhoo??
Generally, the module may wish to establish the identity of the user requesting
a service. This may not be the same as the username returned by pam_get_user().
Indeed, that is only going to be the name of the user under whose identity the
service will be given. This is not necessarily the user that requests the
service.
In other words, user X runs a program that is setuid-Y, it grants the user to
have the permissions of Z. A specific example of this sort of service request
is the ssuu program: user jjooee executes ssuu to become the user jjaannee. In this
situation X=jjooee, Y=rroooott and Z=jjaannee. Clearly, it is important that the module
does not confuse these different users and grant an inappropriate level of
privilege.
The following is the convention to be adhered to when juggling user-identities.
    * X, the identity of the user invoking the service request. This is the
      user identifier; returned by the function getuid(2).
    * Y, the privileged identity of the application used to grant the requested
      service. This is the eeffffeeccttiivvee user identifier; returned by the function
      geteuid(2).
    * Z, the user under whose identity the service will be granted. This is the
      username returned by pam_get_user() and also stored in the LLiinnuuxx--PPAAMM
      item, PPAAMM__UUSSEERR.
    * LLiinnuuxx--PPAAMM has a place for an additional user identity that a module may
      care to make use of. This is the PPAAMM__RRUUSSEERR item. Generally, network
      sensitive modules/applications may wish to set/read this item to
      establish the identity of the user requesting a service from a remote
      location.
Note, if a module wishes to modify the identity of either the uuiidd or eeuuiidd of
the running process, it should take care to restore the original values prior
to returning control to the LLiinnuuxx--PPAAMM library.
55..11..33.. UUssiinngg tthhee ccoonnvveerrssaattiioonn ffuunnccttiioonn
Prior to calling 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!
The module should be prepared for a failure from the conversation. The generic
error would be PPAAMM__CCOONNVV__EERRRR, but anything other than PPAAMM__SSUUCCCCEESSSS should be
treated as indicating failure.
55..11..44.. AAuutthheennttiiccaattiioonn ttookkeennss
To ensure that the authentication tokens are not left lying around the items,
PPAAMM__AAUUTTHHTTOOKK and PPAAMM__OOLLDDAAUUTTHHTTOOKK, 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 LLiinnuuxx--PPAAMM 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;
}
55..22.. UUssee ooff ssyysslloogg((33))
Only rarely should error information be directed to the user. Usually, this is
to be limited to ssoorrrryy yyoouu ccaannnnoott llooggiinn nnooww type messages. Information
concerning errors in the configuration file, /etc/pam.conf, or due to some
system failure encountered by the module, should be written to syslog(3) with
ffaacciilliittyy--ttyyppee LLOOGG__AAUUTTHHPPRRIIVV.
With a few exceptions, the level of logging is, at the discretion of the module
developer. Here is the recommended usage of different logging levels:
    * As a general rule, errors encountered by a module should be logged at the
      LLOOGG__EERRRR level. However, information regarding an unrecognized argument,
      passed to a module from an entry in the /etc/pam.conf file, is rreeqquuiirreedd
      to be logged at the LLOOGG__EERRRR level.
    * Debugging information, as activated by the ddeebbuugg argument to the module
      in /etc/pam.conf, should be logged at the LLOOGG__DDEEBBUUGG level.
    * If a module discovers that its personal configuration file or some system
      file it uses for information is corrupted or somehow unusable, it should
      indicate this by logging messages at level, LLOOGG__AALLEERRTT.
    * Shortages of system resources, such as a failure to manipulate a file or
      malloc() failures should be logged at level LLOOGG__CCRRIITT.
    * Authentication failures, associated with an incorrectly typed password
      should be logged at level, LLOOGG__NNOOTTIICCEE.
55..33.. MMoodduulleess tthhaatt rreeqquuiirree ssyysstteemm lliibbrraarriieess
Writing a module is much like writing an application. You have to provide the
"conventional hooks" for it to work correctly, like pam_sm_authenticate() etc.,
which would correspond to the main() function in a normal function.
Typically, the author may want to link against some standard system libraries.
As when one compiles a normal program, this can be done for modules too: you
simply append the --llXXXXXX arguments for the desired libraries when you create the
shared module object. To make sure a module is linked to the lliibbwwhhaatteevveerr..ssoo
library when it is dlopen()ed, try:
% gcc -shared -o pam_module.so pam_module.o -lwhatever
CChhaapptteerr 66.. AAnn eexxaammppllee mmoodduullee
At some point, we may include a fully commented example of a module in this
document. For now, please look at the modules directory of the LLiinnuuxx--PPAAMM
sources.
CChhaapptteerr 77.. SSeeee aallssoo
    * The Linux-PAM System Administrators' Guide.
    * The Linux-PAM Application Developers' Guide.
    * The V. Samar and R. Schemers (SunSoft), ``UNIFIED LOGIN WITH PLUGGABLE
      AUTHENTICATION MODULES'', Open Software Foundation Request For Comments
      86.0, October 1995.
CChhaapptteerr 88.. AAuutthhoorr//aacckknnoowwlleeddggmmeennttss
This document was written by Andrew G. Morgan (morgan@kernel.org) with many
contributions from Chris Adams, Peter Allgeyer, Tim Baverstock, Tim Berger,
Craig S. Bell, Derrick J. Brashear, Ben Buxton, Seth Chaiklin, Oliver Crow,
Chris Dent, Marc Ewing, Cristian Gafton, Emmanuel Galanos, Brad M. Garcia, Eric
Hester, Roger Hu, Eric Jacksch, Michael K. Johnson, David Kinchlea, Olaf Kirch,
Marcin Korzonek, Thorsten Kukuk, Stephen Langasek, Nicolai Langfeldt, Elliot
Lee, Luke Kenneth Casson Leighton, Al Longyear, Ingo Luetkebohle, Marek
Michalkiewicz, Robert Milkowski, Aleph One, Martin Pool, Sean Reifschneider,
Jan Rekorajski, Erik Troan, Theodore Ts'o, Jeff Uphoff, Myles Uyema, Savochkin
Andrey Vladimirovich, Ronald Wahl, David Wood, John Wilmes, Joseph S. D. Yao
and Alex O. Yuriev.
Thanks are also due to Sun Microsystems, especially to Vipin Samar and Charlie
Lai for their advice. At an early stage in the development of LLiinnuuxx--PPAAMM, Sun
graciously made the documentation for their implementation of PAM available.
This act greatly accelerated the development of LLiinnuuxx--PPAAMM.
CChhaapptteerr 99.. CCooppyyrriigghhtt iinnffoorrmmaattiioonn ffoorr tthhiiss ddooccuummeenntt
Copyright (c) 2006 Thorsten Kukuk <kukuk@thkukuk.de>
Copyright (c) 1996-2002 Andrew G. Morgan <morgan@kernel.org>
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright
   notice, and the entire permission notice in its entirety,
   including the disclaimer of warranties.

2. Redistributions in binary form must reproduce the above copyright
   notice, this list of conditions and the following disclaimer in the
   documentation and/or other materials provided with the distribution.

3. The name of the author may not be used to endorse or promote
   products derived from this software without specific prior
   written permission.
Alternatively, this product may be distributed under the terms of the GNU
General Public License (GPL), in which case the provisions of the GNU GPL are
required instead of the above restrictions. (This clause is necessary due to a
potential bad interaction between the GNU GPL and the restrictions contained in
a BSD-style copyright.)
THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
