- 论坛徽章:
- 0
|
NAME
pam.conf - configuration file for pluggable authentication
modules
SYNOPSIS
/etc/pam.conf
DESCRIPTION
pam.conf is the configuration file for the Pluggable Authen-
tication Module architecture, or PAM. A PAM module pro-
vides functionality for one or more of four possible ser-
vices: authentication, account management, session manage-
ment, and password management. An authentication service
module provides functionality to authenticate a user and
set up user credentials. An account management module pro-
vides functionality to determine if the current user's
account is valid. This includes checking for password and
account expiration, as well as verifying access hour res-
trictions. A session management module provides functional-
ity to set up and terminate login sessions. A password
management module provides functionality to change a user's
authentication token or password. Each of the four service
modules can be implemented as a shared library object which
can be referenced in the pam.conf configuration file.
Simplified PAM.CONF configuration file
The pam.conf file contains a listing of services.
Each service is paired with a corresponding service
module. When a service is requested, its associated module
is invoked. Each entry has the following format:
service_name module_type control_flag module_path options
Below is an example of the pam.conf configuration file with
support for authentication, account management, and session
management modules.
login auth required /usr/lib/security/$ISA/pam_unix.so.1 debug
login session required /usr/lib/security/$ISA/pam_unix.so.1
login account required /usr/lib/security/$ISA/pam_unix.so.1
telnet session required /usr/lib/security/$ISA/pam_unix.so.1
other auth required /usr/lib/security/$ISA/pam_unix.so.1
other passwd required /usr/lib/security/$ISA/pam_unix.so.1
The service_name denotes the service (for example, login,
dtlogin, or rlogin). The keyword, other, indicates the
module all other applications which have not been specified
should use.
The other keyword can also be used if all services of the
same module_type have the same requirements.
In the example above, since all of the services use the
same session module, they could have been replace by a
SunOS 5.8 Last change: 29 Oct 1999 1
File Formats pam.conf(4)
single other line.
module_type denotes the service module type: authentication
(auth), account management (account), session management
(session), or password management (password).
The control_flag field determines the behavior of stacking,
and will be discussed in more detail below.
The module_path field specifies the pathname to a shared
library
object which implements the service functionality. If the
pathname is not absolute, it is assumed to be relative to
/usr/lib/security/$ISA/. If the pathname contains the $ISA
token, that token is replaced by an implementation defined
directory name which defines the path relative to the cal-
ling program's instruction set architecture.
The options field is used by the PAM framework layer to pass
module specific options to the modules. It is up to the
module to parse and interpret the options.
This field can be used by the modules to turn on debugging
or to pass any module specific parameters such as a TIMEOUT
value. It can also be used to support unified login. The
options supported by the modules are documented in their
respective manual pages. For example, pam_unix(5) lists the
options accepted by the UNIX module.
Integrating Multiple Authentication Services With Stacking
When a service_name of the same module_type is defined more
than once, the service is said to be stacked. Each module
referenced in the module_path for that service is then pro-
cessed in the order that it occurs in the configuration
file. The control_flag field specifies the continuation and
failure semantics of the modules, and may be requisite,
required, optional, or sufficient.
The PAM framework processes each service module in the
stack. If all requisite and required modules in the stack
succeed, then success is returned, and optional and suffi-
cient error values are ignored. If one or more requisite or
required modules fail, then the error value from the first
requisite or required module that failed is returned.
If none of the service modules in the stack are designated
as requisite or required, then the
PAM framework requires that at least one optional or suffi-
cient module succeed.
If all fail then the error value from the first service
module in the stack is returned.
SunOS 5.8 Last change: 29 Oct 1999 2
File Formats pam.conf(4)
The requisite and sufficient flags cause two exceptions to
the above semantics. If a service module that is designated
as requisite fails, then the PAM framework immediately
returns an error to the application, and all subsequent ser-
vice modules in the stack are ignored. If a prior required
service module has failed, then that error is returned. If
no prior required service module failed, then the error from
the failed requisite service module is returned.
If a service module that is designated as sufficient
succeeds, then the PAM framework immediately returns success
to the application, and all subsequent services modules in
the stack, even requisite and required ones, are ignored,
given that all prior requisite and required modules have
also succeeded. If a prior required module has failed, then
the error value from that module is returned.
If any entry in pam.conf is incorrect, or if a module does
not exist or cannot be opened, then all PAM services will
fail and users will not be permitted access to the system.
An error will be logged through syslog(3C) at the LOG_CRIT
level. To fix incorrect entries in pam.conf, a system
administrator may boot the system in maintenance mode (sin-
gle user) to edit the file. Below is a sample configuration
file that stacks the su, login, and rlogin services.
su auth requisite /usr/lib/security/$ISA/pam_inhouse.so.1
su auth required /usr/lib/security/$ISA/pam_unix.so.1 debug
login auth required /usr/lib/security/$ISA/pam_unix.so.1 debug
login auth optional /usr/lib/security/$ISA/pam_inhouse.so.1
rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1
In the case of su, the user is authenticated by the Inhouse
and UNIX authentication modules. Because the Inhouse and
UNIX authentication modules are requisite and required,
respectively, an error is returned back to the application
if either module fails. In addition, if the requisite
authentication (Inhouse authentication) fails, the UNIX
authentication module is never invoked, and the error is
returned immediately back to the application.
In the case of login, the required keyword for control_flag
requires that the user be allowed to login only if the user
is authenticated by the UNIX service module. If UNIX
authentication fails, control continues to proceed down the
stack, and the Inhouse authentication module is invoked.
Inhouse authentication is optional by virtue of the
optional keyword in the control_flag field.
The user can still log in even if Inhouse authentication
fails, assuming the UNIX authentication succeeded.
SunOS 5.8 Last change: 29 Oct 1999 3
File Formats pam.conf(4)
In the case of rlogin, the sufficient keyword for
control_flag specifies that if the rhosts authentication
check succeeds, then PAM should return success to rlogin
and rlogin should not prompt the user for a password. The
UNIX authentication module, which is the next module in the
stack, will only be invoked if the rhosts check fails. This
gives the system administrator the flexibility to determine
if rhosts alone is sufficient enough to authenticate a
remote user.
Some modules may return PAM_IGNORE in certain situations. In
these cases the PAM framework ignores the entire entry in
pam.conf regardless of whether or not it is
requisite, required, optional or sufficient.
Utilities and Files
A following is a list of the utilities that are known to use
PAM: include: login, passwd, su, rlogind, rshd, telnetd,
ftpd, rpc.rexd, uucpd, init, sac, and ttymon.
The utility dtlogin also uses PAM. Note however that dtlo-
gin is the login service utility for the Common Desktop
Environment (CDE).
The PAM configuration file does not dictate either the name
or the location of the service specific modules.
The convention, however, is the following:
/usr/lib/security/$ISA/pam_module_name.so.x
Implements various function of specific authentication
services.
/etc/pam.conf
Configuration file.
/usr/lib/$ISA/libpam.so.1
Implements the PAM framework library.
EXAMPLES
Example 1: A sample pam.conf configuration file.
The following is a sample pam.conf configuration file.
Lines that begin with the # symbol are treated as comments,
and therefore ignored.
#
# PAM configuration
#
# Authentication management for login service is stacked.
# Both UNIX and inhouse authentication functions are invoked.
login auth required /usr/lib/security/$ISA/pam_unix.so.1
SunOS 5.8 Last change: 29 Oct 1999 4
File Formats pam.conf(4)
login auth required /usr/lib/security/$ISA/pam_inhouse.so.1 try_first_pass
dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1
dtlogin auth required /usr/lib/security/$ISA/pam_inhouse.so.1 try_first_pass
#
# Authentication management for rlogin service is stacked.
# If the rhost check succeeds, do not continue
rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1
rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1
#
# Other services use UNIX authentication
other auth required /usr/lib/security/$ISA/pam_unix.so.1
#
# Account management for login service is stacked.
# UNIX account management is required
# Inhouse account management is optional
login account required /usr/lib/security/$ISA/pam_unix.so.1
login account optional /usr/lib/security/$ISA/pam_inhouse.so.1
dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1
dtlogin account optional /usr/lib/security/$ISA/pam_inhouse.so.1
other account required /usr/lib/security/$ISA/pam_unix.so.1
#
# Session management
other session required /usr/lib/security/$ISA/pam_unix.so.1
#
# Password management
other password required /usr/lib/security/$ISA/pam_unix.so.1
ATTRIBUTES
See attributes(5) for description of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| MT Level | MT-Safe with exceptions |
|_____________________________|_____________________________|
SEE ALSO
login(1), passwd(1), in.ftpd(1M), in.rlogind(1M),
in.rshd(1M), in.telnetd(1M), in.uucpd(1M), init(1M),
rpc.rexd(1M), sac(1M), su(1M), ttymon(1M), pam(3PAM),
syslog(3C), libpam(3LIB), attributes(5), pam_unix(5)
NOTES
The interfaces in libpam() are MT-Safe only if each thread
within the multi-threaded application uses its own PAM han-
dle. |
|
免费注册
发表于 2008-03-27 10:01
