The syntax and semantics of the PAM configuration data are part of this specification. However, the physical form in which that configuration data is stored is not specified.
Existing implementations of PAM utilize a file, pam.conf, located on each platform supporting PAM to hold the PAM configuration data. It is not a requirement of this specification that an implementation needs to support a local pam.conf file. A centralized service could be provided for ease of administration.
The current PAM configuration syntax supports the definition of PAM behavior on a host/service basis. The possibility of extending the PAM configuration file to include user identities and thus support a host/user/service basis has been discussed during the development of this specification but has been deferred to a future version.
This specification does not include any definition of the way in which underlying modules are configured, except where module specific parameters are to be included in the options field as part of an entry within the PAM configuration data. The purpose and value of this specification is to define a common interface to authentication and other types of modules. The mechanism by which the modules used are configured is implementation specific.
It is not a requirement for the module providers to use mapped user
names or passwords. If mapping is supported, the module provider should
document whether mapping is provided and whether for user
names, passwords, or both. The system administrator can enable mapping
on a per application basis through the use of option flags such as
"map=user" or "map=pass". Based on such flags, the modules
should call
It is the responsibility of the PAM engine to load the mapping services and route the "get" and "set" calls to the appropriate mapping services, and return appropriate status to the calling module. This is very similar to the way PAM engine handles other PAM types such as auth.
If there are multiple mapping modules, the semantics of the control flags (that is, optional, required, and sufficient) require special attention. With multiple mapping services, the desired semantics are that the result from the first successful map will be used. For updates, the new map should be sent to all the configured mapping services so that the appropriate mapping service gets updated. Thus for the get calls, the semantics required are of the sufficient flag, and for the set calls, the semantics required are of the optional flag.
option
or
option_name=option_value
WHITE SPACE is delimiter between options
Proprietary option names may be used. Collision with standard names is considered to be unlikely and easily addressed by one or other names being changed.
Option names should be registered with The Open Group.
The list of registered names will be published by The Open Group,
and details about the procedure for registering new option names
will also be published. For further details write to:
OGsecurity-request@opengroup.org
That document also describes the procedure for registering new option names.
Contents | Next section | Index |