Whitespace cleanup.
This commit is contained in:
Dag-Erling Smørgrav
parent
aedc109557
commit
f5b32f0bef
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=13317
1 changed files with 182 additions and 182 deletions
|
|
@ -45,9 +45,9 @@
|
|||
|
||||
<abstract>
|
||||
<para>This article describes the underlying principles and
|
||||
mechanisms of the Pluggable Authentication Modules (PAM)
|
||||
library, and explains how to configure PAM, how to integrate
|
||||
PAM into applications, and how to write PAM modules.</para>
|
||||
mechanisms of the Pluggable Authentication Modules (PAM)
|
||||
library, and explains how to configure PAM, how to integrate
|
||||
PAM into applications, and how to write PAM modules.</para>
|
||||
</abstract>
|
||||
|
||||
<authorgroup>
|
||||
|
|
@ -85,14 +85,14 @@
|
|||
<title>Trademarks</title>
|
||||
|
||||
<para>Sun, Sun Microsystems and Solaris are trademarks or
|
||||
registered trademarks of Sun Microsystems, Inc.</para>
|
||||
registered trademarks of Sun Microsystems, Inc.</para>
|
||||
|
||||
<para>UNIX and The Open Group are trademarks or registered
|
||||
trademarks of The Open Group.</para>
|
||||
trademarks of The Open Group.</para>
|
||||
|
||||
<para>All other brand or product names mentioned in this
|
||||
document may be trademarks or registered trademarks of their
|
||||
respective owners.</para>
|
||||
document may be trademarks or registered trademarks of their
|
||||
respective owners.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
|
|
@ -103,43 +103,43 @@
|
|||
<title id="pam-definitions.title">Definitions</title>
|
||||
|
||||
<para>The terminology surrounding PAM is rather confused.
|
||||
Neither Samar and Lai's original paper nor the XSSO
|
||||
specification made any attempt at formally defining terms for
|
||||
the various actors and entities involved in PAM, and the terms
|
||||
that they do use (but do not define) are sometimes misleading
|
||||
and ambiguous. The first attempt at establishing a consistent
|
||||
and unambiguous terminology was a whitepaper written by Andrew
|
||||
G. Morgan (author of Linux-PAM) in 1999. While Morgan's
|
||||
choice of terminology was a huge leap forward, it is in this
|
||||
author's opinion by no means perfect. What follows is an
|
||||
attempt, heavily inspired by Morgan, to define precise and
|
||||
unambiguous terms for all actors and entities involved in
|
||||
PAM.</para>
|
||||
Neither Samar and Lai's original paper nor the XSSO
|
||||
specification made any attempt at formally defining terms for
|
||||
the various actors and entities involved in PAM, and the terms
|
||||
that they do use (but do not define) are sometimes misleading
|
||||
and ambiguous. The first attempt at establishing a consistent
|
||||
and unambiguous terminology was a whitepaper written by Andrew
|
||||
G. Morgan (author of Linux-PAM) in 1999. While Morgan's
|
||||
choice of terminology was a huge leap forward, it is in this
|
||||
author's opinion by no means perfect. What follows is an
|
||||
attempt, heavily inspired by Morgan, to define precise and
|
||||
unambiguous terms for all actors and entities involved in
|
||||
PAM.</para>
|
||||
|
||||
<glosslist>
|
||||
<glossentry>
|
||||
<glossterm>account</glossterm>
|
||||
<glossentry>
|
||||
<glossterm>account</glossterm>
|
||||
<glossdef>
|
||||
<para>The set of credentials the applicant is requesting
|
||||
from the arbitrator.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>applicant</glossterm>
|
||||
<glossentry>
|
||||
<glossterm>applicant</glossterm>
|
||||
<glossdef>
|
||||
<para>The user or entity requesting authentication.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>arbitrator</glossterm>
|
||||
<glossentry>
|
||||
<glossterm>arbitrator</glossterm>
|
||||
<glossdef>
|
||||
<para>The user or entity who has the privileges necessary
|
||||
to verify the applicant's credentials and the authority
|
||||
to grant or deny the request.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>chain</glossterm>
|
||||
|
|
@ -152,15 +152,15 @@
|
|||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>client</glossterm>
|
||||
<glossentry>
|
||||
<glossterm>client</glossterm>
|
||||
<glossdef>
|
||||
<para>The application responsible for initiating an
|
||||
authentication request on behalf of the applicant and
|
||||
for obtaining the necessary authentication information
|
||||
from him.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>facility</glossterm>
|
||||
|
|
@ -193,15 +193,15 @@
|
|||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>server</glossterm>
|
||||
<glossentry>
|
||||
<glossterm>server</glossterm>
|
||||
<glossdef>
|
||||
<para>The application acting on behalf of the arbitrator
|
||||
to converse with the client, retrieve authentication
|
||||
information, verify the applicant's credentials and
|
||||
grant or deny requests.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>service</glossterm>
|
||||
|
|
@ -249,11 +249,11 @@
|
|||
<title>Usage examples</title>
|
||||
|
||||
<para>This section aims to illustrate the meanings of some of
|
||||
the terms defined above by way of a handful of simple
|
||||
examples.</para>
|
||||
the terms defined above by way of a handful of simple
|
||||
examples.</para>
|
||||
|
||||
<section>
|
||||
<title>Client and server are one</title>
|
||||
<title>Client and server are one</title>
|
||||
|
||||
<para>This simple example shows <literal>alice</literal>
|
||||
&man.su.1;'ing to <literal>root</literal>.</para>
|
||||
|
|
@ -291,7 +291,7 @@ root
|
|||
</section>
|
||||
|
||||
<section>
|
||||
<title>Client and server are separate</title>
|
||||
<title>Client and server are separate</title>
|
||||
|
||||
<para>The example below shows <literal>eve</literal> try to
|
||||
initiate an &man.ssh.1; connection to
|
||||
|
|
@ -305,7 +305,7 @@ eve
|
|||
bob@login.example.com's password: <userinput>god</userinput>
|
||||
Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1
|
||||
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
|
||||
The Regents of the University of California. All rights reserved.
|
||||
The Regents of the University of California. All rights reserved.
|
||||
FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001
|
||||
|
||||
Welcome to FreeBSD!
|
||||
|
|
@ -337,7 +337,7 @@ Welcome to FreeBSD!
|
|||
</section>
|
||||
|
||||
<section>
|
||||
<title>Sample policy</title>
|
||||
<title>Sample policy</title>
|
||||
|
||||
<para>The following is FreeBSD's default policy for
|
||||
<literal>sshd</literal>:</para>
|
||||
|
|
@ -351,9 +351,9 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>This policy applies to the <literal>sshd</literal>
|
||||
service (which is not necessarily restricted to the
|
||||
&man.sshd.8; server.)</para>
|
||||
<para>This policy applies to the <literal>sshd</literal>
|
||||
service (which is not necessarily restricted to the
|
||||
&man.sshd.8; server.)</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para><literal>auth</literal>, <literal>account</literal>,
|
||||
|
|
@ -385,13 +385,13 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<section id="pam-facilities-primitives">
|
||||
<title id="pam-facilities-primitives.title">Facilities and
|
||||
primitives</title>
|
||||
primitives</title>
|
||||
|
||||
<para>The PAM API offers six different authentication primitives
|
||||
grouped in four facilities, which are described below.</para>
|
||||
grouped in four facilities, which are described below.</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>auth</literal></term>
|
||||
<listitem>
|
||||
<para><emphasis>Authentication.</emphasis> This facility
|
||||
|
|
@ -401,23 +401,23 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><function>pam_authenticate</function>
|
||||
authenticates the applicant, usually by requesting
|
||||
an authentication token and comparing it with a
|
||||
value stored in a database or obtained from an
|
||||
authentication server.</para>
|
||||
<para><function>pam_authenticate</function>
|
||||
authenticates the applicant, usually by requesting
|
||||
an authentication token and comparing it with a
|
||||
value stored in a database or obtained from an
|
||||
authentication server.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><function>pam_setcred</function> establishes
|
||||
account credentials such as user ID, group
|
||||
membership and resource limits.</para>
|
||||
<para><function>pam_setcred</function> establishes
|
||||
account credentials such as user ID, group
|
||||
membership and resource limits.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>account</literal></term>
|
||||
<listitem>
|
||||
<para><emphasis>Account management.</emphasis> This
|
||||
|
|
@ -428,14 +428,14 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><function>pam_acct_mgmt</function> verifies that
|
||||
the requested account is available.</para>
|
||||
<para><function>pam_acct_mgmt</function> verifies that
|
||||
the requested account is available.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>session</literal></term>
|
||||
<listitem>
|
||||
<para><emphasis>Session management.</emphasis> This
|
||||
|
|
@ -445,25 +445,25 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><function>pam_open_session</function> performs
|
||||
tasks associated with session set-up: add an entry
|
||||
in the <filename>utmp</filename> and
|
||||
<filename>wtmp</filename> databases, start an SSH
|
||||
agent, etc.</para>
|
||||
<para><function>pam_open_session</function> performs
|
||||
tasks associated with session set-up: add an entry
|
||||
in the <filename>utmp</filename> and
|
||||
<filename>wtmp</filename> databases, start an SSH
|
||||
agent, etc.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><function>pam_close_session</function> performs
|
||||
tasks associated with session tear-down: add an
|
||||
entry in the <filename>utmp</filename> and
|
||||
<filename>wtmp</filename> databases, stop the SSH
|
||||
agent, etc.</para>
|
||||
<para><function>pam_close_session</function> performs
|
||||
tasks associated with session tear-down: add an
|
||||
entry in the <filename>utmp</filename> and
|
||||
<filename>wtmp</filename> databases, stop the SSH
|
||||
agent, etc.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>password</literal></term>
|
||||
<listitem>
|
||||
<para><emphasis>Password management.</emphasis> This
|
||||
|
|
@ -474,10 +474,10 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para><function>pam_chauthtok</function> changes the
|
||||
authentication token, optionally verifying that it
|
||||
is sufficiently hard to guess, has not been used
|
||||
previously, etc.</para>
|
||||
<para><function>pam_chauthtok</function> changes the
|
||||
authentication token, optionally verifying that it
|
||||
is sufficiently hard to guess, has not been used
|
||||
previously, etc.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
|
@ -490,49 +490,49 @@ sshd password required pam_permit.so</programlisting>
|
|||
<title>Modules</title>
|
||||
|
||||
<para>Modules are a very central concept in PAM; after all,
|
||||
they are the <quote>M</quote> in <quote>PAM</quote>. A PAM
|
||||
module is a self-contained piece of program code that
|
||||
implements the primitives in one or more facilities for one
|
||||
particular mechanism; possible mechanisms for the
|
||||
authentication facility, for instance, include the UNIX
|
||||
password database, NIS, LDAP and Radius.</para>
|
||||
they are the <quote>M</quote> in <quote>PAM</quote>. A PAM
|
||||
module is a self-contained piece of program code that
|
||||
implements the primitives in one or more facilities for one
|
||||
particular mechanism; possible mechanisms for the
|
||||
authentication facility, for instance, include the UNIX
|
||||
password database, NIS, LDAP and Radius.</para>
|
||||
|
||||
<para>FreeBSD groups all facilities for the same mechanism in
|
||||
one module called
|
||||
one module called
|
||||
<literal>pam_<replaceable>mechanism</replaceable>.so</literal> (e.g.
|
||||
<literal>pam_unix.so</literal>.) The original PAM
|
||||
implementation, on the other hand, had separate modules for
|
||||
each facility, called
|
||||
<literal>pam_<replaceable>mechanism</replaceable>_<replaceable>facility</replaceable>.so</literal>
|
||||
implementation, on the other hand, had separate modules for
|
||||
each facility, called
|
||||
<literal>pam_<replaceable>mechanism</replaceable>_<replaceable>facility</replaceable>.so</literal>
|
||||
(e.g. <literal>pam_unix_auth.so</literal>.)</para>
|
||||
</section>
|
||||
|
||||
<section id="pam-chains-policies">
|
||||
<title id="pam-chains-policies.title">Chains and
|
||||
policies</title>
|
||||
policies</title>
|
||||
|
||||
<para>When a server initiates a PAM transaction, the PAM library
|
||||
tries to load a policy for the service specified in the
|
||||
<function>pam_start</function> call. The policy specifies how
|
||||
authentication requests should be processed, and is defined in
|
||||
a configuration file. This is the other central concept in
|
||||
PAM: the possibility for the admin to tune the system security
|
||||
policy (in the wider sense of the word) simply by editing a
|
||||
text file.</para>
|
||||
tries to load a policy for the service specified in the
|
||||
<function>pam_start</function> call. The policy specifies how
|
||||
authentication requests should be processed, and is defined in
|
||||
a configuration file. This is the other central concept in
|
||||
PAM: the possibility for the admin to tune the system security
|
||||
policy (in the wider sense of the word) simply by editing a
|
||||
text file.</para>
|
||||
|
||||
<para>A policy consists of four chains, one for each of the four
|
||||
PAM facilities. Each chain is a sequence of configuration
|
||||
statements, each specifying a module to invoke, some
|
||||
(optional) parameters to pass to the module, and a control
|
||||
flag that describes how to interpret the return code from the
|
||||
module.</para>
|
||||
PAM facilities. Each chain is a sequence of configuration
|
||||
statements, each specifying a module to invoke, some
|
||||
(optional) parameters to pass to the module, and a control
|
||||
flag that describes how to interpret the return code from the
|
||||
module.</para>
|
||||
|
||||
<para>Understanding the control flags is essential to
|
||||
understanding PAM configuration files. There are four
|
||||
different control flags:</para>
|
||||
understanding PAM configuration files. There are four
|
||||
different control flags:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>required</literal></term>
|
||||
<listitem>
|
||||
<para>Success is required, but the chain continues no
|
||||
|
|
@ -541,7 +541,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>requisite</literal></term>
|
||||
<listitem>
|
||||
<para>A negative result from this module will immediately
|
||||
|
|
@ -549,7 +549,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>sufficient</literal></term>
|
||||
<listitem>
|
||||
<para>A positive result from this module will immediately
|
||||
|
|
@ -558,7 +558,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<varlistentry>
|
||||
<term><literal>optional</literal></term>
|
||||
<listitem>
|
||||
<para>A negative result from this module will be
|
||||
|
|
@ -568,34 +568,34 @@ sshd password required pam_permit.so</programlisting>
|
|||
</variablelist>
|
||||
|
||||
<para>When a server invokes one of the six PAM primitives, PAM
|
||||
retrieves the chain for the facility the primitive belongs to,
|
||||
and invokes each of the modules listed in the chain, in the
|
||||
order they are listed, until it reaches the end, or determines
|
||||
that no further processing is necessary (either because a
|
||||
<literal>sufficient</literal> module succeeded, or because a
|
||||
<literal>requisite</literal> module failed.) The request is
|
||||
granted if and only if at least one module was invoked, and
|
||||
all non-optional modules succeeded.</para>
|
||||
retrieves the chain for the facility the primitive belongs to,
|
||||
and invokes each of the modules listed in the chain, in the
|
||||
order they are listed, until it reaches the end, or determines
|
||||
that no further processing is necessary (either because a
|
||||
<literal>sufficient</literal> module succeeded, or because a
|
||||
<literal>requisite</literal> module failed.) The request is
|
||||
granted if and only if at least one module was invoked, and
|
||||
all non-optional modules succeeded.</para>
|
||||
|
||||
<para>Note that it is possible, though not very common, to have
|
||||
the same module listed several times in the same chain. For
|
||||
instance, a module that looks up user names and passwords in a
|
||||
directory server could be invoked multiple times with
|
||||
different parameters specifying different directory servers to
|
||||
contact. PAM treat different occurrences of the same module
|
||||
in the same chain as different, unrelated modules.</para>
|
||||
the same module listed several times in the same chain. For
|
||||
instance, a module that looks up user names and passwords in a
|
||||
directory server could be invoked multiple times with
|
||||
different parameters specifying different directory servers to
|
||||
contact. PAM treat different occurrences of the same module
|
||||
in the same chain as different, unrelated modules.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Transactions</title>
|
||||
|
||||
<para>The lifecycle of a typical PAM transaction is described
|
||||
below. Note that if this any of these steps fails, the server
|
||||
should report a suitable error message to the client and abort
|
||||
the transaction.</para>
|
||||
below. Note that if this any of these steps fails, the server
|
||||
should report a suitable error message to the client and abort
|
||||
the transaction.</para>
|
||||
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>If necessary, the server obtains arbitrator
|
||||
credentials through a mechanism independent of
|
||||
PAM—most commonly by virtue of having been started
|
||||
|
|
@ -603,7 +603,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
<literal>root</literal>.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<listitem>
|
||||
<para>The server calls <function>pam_start</function> to
|
||||
initialize the PAM library and specify its service name
|
||||
and the target account, and register a suitable
|
||||
|
|
@ -682,63 +682,63 @@ sshd password required pam_permit.so</programlisting>
|
|||
<title>Location of configuration files</title>
|
||||
|
||||
<para>The traditional PAM configuration file is
|
||||
<filename>/etc/pam.conf</filename>. This file contains all
|
||||
the PAM policies for your system. Each line of the file
|
||||
describes one step in a chain, as shown below:</para>
|
||||
<filename>/etc/pam.conf</filename>. This file contains all
|
||||
the PAM policies for your system. Each line of the file
|
||||
describes one step in a chain, as shown below:</para>
|
||||
|
||||
<programlisting>login auth required pam_nologin.so no_warn</programlisting>
|
||||
|
||||
<para>The fields are, in order: service name, facility name,
|
||||
control flag, module name, and module arguments. Any
|
||||
additional fields are interpreted as additional module
|
||||
arguments.</para>
|
||||
control flag, module name, and module arguments. Any
|
||||
additional fields are interpreted as additional module
|
||||
arguments.</para>
|
||||
|
||||
<para>A separate chain is constructed for each service /
|
||||
facility pair, so while the order in which lines for the same
|
||||
service and facility appear is significant, the order in which
|
||||
the individual services and facilities are listed is
|
||||
not—except that entries for the <literal>other</literal>
|
||||
service, which serves as a fall-back, should come last. The
|
||||
examples in the original PAM paper grouped configuration lines
|
||||
by facility, and Solaris' stock <filename>pam.conf</filename>
|
||||
still does that, but Linux-PAM (and hence FreeBSD) groups
|
||||
configuration lines by service. Either way is fine; either
|
||||
way makes equal sense.</para>
|
||||
facility pair, so while the order in which lines for the same
|
||||
service and facility appear is significant, the order in which
|
||||
the individual services and facilities are listed is
|
||||
not—except that entries for the <literal>other</literal>
|
||||
service, which serves as a fall-back, should come last. The
|
||||
examples in the original PAM paper grouped configuration lines
|
||||
by facility, and Solaris' stock <filename>pam.conf</filename>
|
||||
still does that, but Linux-PAM (and hence FreeBSD) groups
|
||||
configuration lines by service. Either way is fine; either
|
||||
way makes equal sense.</para>
|
||||
|
||||
<para>Linux-PAM offers an alternate configuration mechanism,
|
||||
where policies are contained in separate files, named for the
|
||||
service they apply to, in <filename>/etc/pam.d/</filename>,
|
||||
with only four fields instead of five—the service name
|
||||
field is omitted. In FreeBSD 5.0, starting from mid-January
|
||||
2002, this is the preferred mechanism. Note, however, that if
|
||||
<filename>/etc/pam.conf</filename> exists, and contains
|
||||
configuration statements for services which do not have a
|
||||
specific policy in <filename>/etc/pam.d/</filename>, it will
|
||||
be used as a fall-back for these services.</para>
|
||||
where policies are contained in separate files, named for the
|
||||
service they apply to, in <filename>/etc/pam.d/</filename>,
|
||||
with only four fields instead of five—the service name
|
||||
field is omitted. In FreeBSD 5.0, starting from mid-January
|
||||
2002, this is the preferred mechanism. Note, however, that if
|
||||
<filename>/etc/pam.conf</filename> exists, and contains
|
||||
configuration statements for services which do not have a
|
||||
specific policy in <filename>/etc/pam.d/</filename>, it will
|
||||
be used as a fall-back for these services.</para>
|
||||
|
||||
<para>The great advantage of <filename>/etc/pam.d/</filename>
|
||||
over <filename>/etc/pam.conf</filename> is that it is possible
|
||||
to use the same policy for multiple services by linking each
|
||||
service name to a same policy file. For instance, to use the
|
||||
same policy for the <literal>su</literal> and
|
||||
<literal>sudo</literal> services, one could do as
|
||||
follows:</para>
|
||||
over <filename>/etc/pam.conf</filename> is that it is possible
|
||||
to use the same policy for multiple services by linking each
|
||||
service name to a same policy file. For instance, to use the
|
||||
same policy for the <literal>su</literal> and
|
||||
<literal>sudo</literal> services, one could do as
|
||||
follows:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>cd /etc/pam.d</userinput>
|
||||
&prompt.root; <userinput>ln -s su sudo</userinput></screen>
|
||||
|
||||
<para>This works because the service name is determined from the
|
||||
file name rather than specified in the policy file, so the
|
||||
same file can be used for arbitrary services.</para>
|
||||
file name rather than specified in the policy file, so the
|
||||
same file can be used for arbitrary services.</para>
|
||||
|
||||
<para>One other advantage is that third-party software can
|
||||
easily install policies for their services without the need to
|
||||
edit <filename>/etc/pam.conf</filename>.</para>
|
||||
easily install policies for their services without the need to
|
||||
edit <filename>/etc/pam.conf</filename>.</para>
|
||||
|
||||
<para>Whether you use <filename>/etc/pam.conf</filename> or
|
||||
<filename>/etc/pam.d/</filename>, the policy for the special
|
||||
service <literal>other</literal> is used as a fall-back for
|
||||
any service that does not have its own policy.</para>
|
||||
<filename>/etc/pam.d/</filename>, the policy for the special
|
||||
service <literal>other</literal> is used as a fall-back for
|
||||
any service that does not have its own policy.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
@ -750,29 +750,29 @@ sshd password required pam_permit.so</programlisting>
|
|||
flag, the module name, and zero or more module arguments.</para>
|
||||
|
||||
<para>The service name is generally (though not always) the name
|
||||
of the application the statement applies to. If you are
|
||||
unsure, refer to the individual application's documentation to
|
||||
determine what service name it uses.</para>
|
||||
of the application the statement applies to. If you are
|
||||
unsure, refer to the individual application's documentation to
|
||||
determine what service name it uses.</para>
|
||||
|
||||
<para>Note that if you use <filename>/etc/pam.d/</filename>
|
||||
instead of <filename>/etc/pam.conf</filename>, the service
|
||||
name is specified by the name of the policy file, and omitted
|
||||
from the actual configuration lines, which then start with the
|
||||
facility name.</para>
|
||||
instead of <filename>/etc/pam.conf</filename>, the service
|
||||
name is specified by the name of the policy file, and omitted
|
||||
from the actual configuration lines, which then start with the
|
||||
facility name.</para>
|
||||
|
||||
<para>The facility is one of the four facility keywords
|
||||
described in the <link linkend="pam-facilities-primitives"
|
||||
endterm="pam-facilities-primitives.title"></link>
|
||||
section.</para>
|
||||
described in the <link linkend="pam-facilities-primitives"
|
||||
endterm="pam-facilities-primitives.title"></link>
|
||||
section.</para>
|
||||
|
||||
<para>Likewise, the control flag is one of the four keywords
|
||||
described in the <link linkend="pam-chains-policies"
|
||||
endterm="pam-chains-policies.title"></link> section,
|
||||
describing how to interpret the return code from the module.
|
||||
Linux-PAM supports an alternate syntax that lets you specify
|
||||
the action to associate with each possible return code, but
|
||||
this should be avoided as it is non-standard and requires very
|
||||
detailed knowledge of the PAM library to use properly.</para>
|
||||
described in the <link linkend="pam-chains-policies"
|
||||
endterm="pam-chains-policies.title"></link> section,
|
||||
describing how to interpret the return code from the module.
|
||||
Linux-PAM supports an alternate syntax that lets you specify
|
||||
the action to associate with each possible return code, but
|
||||
this should be avoided as it is non-standard and requires very
|
||||
detailed knowledge of the PAM library to use properly.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
|
|
@ -794,7 +794,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
<para><!--XXX-->This section has not yet been written.</para>
|
||||
|
||||
<!--
|
||||
|
||||
|
||||
Note that while the original PAM paper includes a sample PAM
|
||||
application that calls pam_open_session() before pam_setcred(),
|
||||
the Linux-PAM documentation states that pam_setcred() must be
|
||||
|
|
@ -803,9 +803,9 @@ sshd password required pam_permit.so</programlisting>
|
|||
Also note that the example in the paper calls setgid(),
|
||||
initgroups() and setuid() itself rather than rely on
|
||||
pam_setcred() to do it.
|
||||
|
||||
|
||||
-->
|
||||
|
||||
|
||||
</section>
|
||||
|
||||
<section id="pam-module-prog">
|
||||
|
|
@ -822,7 +822,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
<function>misc_conv</function> conversation function, which is
|
||||
prototyped in <filename
|
||||
class="headerfile">security/pam_misc.h</filename>.</para>
|
||||
|
||||
|
||||
<programlisting><inlinegraphic fileref="pam_app.c"
|
||||
format="linespecific"></programlisting>
|
||||
</appendix>
|
||||
|
|
@ -838,7 +838,7 @@ sshd password required pam_permit.so</programlisting>
|
|||
|
||||
<abstract>
|
||||
<para>This is a list of documents relevant to PAM and related
|
||||
issues. It is by no means complete.</para>
|
||||
issues. It is by no means complete.</para>
|
||||
</abstract>
|
||||
|
||||
<bibliodiv>
|
||||
|
|
|
|||
Loading…
Reference in a new issue