PAM service modules use pam_get_item(3PAM) and pam_set_item(3PAM) to communicate with applications. To communicate with each other, service modules use pam_get_data(3PAM) and pam_set_data(3PAM). If service modules from the same project need to exchange data, then a unique data name for that project should be established. The service modules can then share this data through the pam_get_data() and pam_set_data() functions.
Service modules must return one of three classes of PAM return code:
PAM_SUCCESS if the module has made a positive decision that is part of the requested policy.
PAM_IGNORE if the module does not make a policy decision.
PAM_error if the module participates in the decision that results in a failure. The error can be either a generic error code or a code specific to the service module type. The error cannot be an error code for another service module type. See the specific man page for pam_sm_module-type for the error codes.
If a service module performs multiple functions, these functions should be split up into separate modules. This approach gives system administrators finer-grained control for configuring policy.
Man pages should be provided for any new service modules. Man pages should include the following items:
Arguments that the module accepts.
All functions that the module implements.
The effect of flags on the algorithm.
Any required PAM items.
Error returns that are specific to this module.
Service modules are required to honor the PAM_SILENT flag for preventing display of messages. The debug argument is recommended for logging debug information to syslog. Use syslog(3C) with LOG_AUTH and LOG_DEBUG for debug logging. Other messages should be sent to syslog() with LOG_AUTH and the appropriate priority. openlog(3C), closelog(3C), and setlogmask(3C) must not be used as these functions interfere with the applications settings.