Requirements for PAM Service Providers

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.