Old uncommitted changes: improve the configuration section, and add

descriptions for more modules.
This commit is contained in:
Dag-Erling Smørgrav 2003-12-10 16:26:44 +00:00
parent e8ae5c0bd2
commit ec88e446c2
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=19123

View file

@ -389,11 +389,13 @@ sshd password required pam_permit.so</programlisting>
</section> </section>
</section> </section>
<!--
<section id="pam-conventions"> <section id="pam-conventions">
<title id="pam-conventions.title">Conventions</title> <title id="pam-conventions.title">Conventions</title>
<para><!--XXX-->This section has not yet been written.</para> <para>This section has not yet been written.</para>
</section> </section>
-->
</section> </section>
<section id="pam-essentials"> <section id="pam-essentials">
@ -750,87 +752,99 @@ sshd password required pam_permit.so</programlisting>
<section id="pam-config"> <section id="pam-config">
<title id="pam-config.title">PAM Configuration</title> <title id="pam-config.title">PAM Configuration</title>
<section id="pam-config-file-locations"> <section id="pam-config-file">
<title id="pam-config-file-locations.title">Location of <title id="pam-config-file.title">PAM policy files</title>
configuration files</title>
<para>The traditional PAM configuration file is <section id="pam-config-pam.conf">
<filename>/etc/pam.conf</filename>. This file contains all <title id="pam-config-pam.conf.title">The
the PAM policies for your system. Each line of the file <filename>/etc/pam.conf</filename> file</title>
describes one step in a chain, as shown below:</para>
<para>The traditional PAM policy 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>
<programlisting>login auth required pam_nologin.so no_warn</programlisting> <programlisting>login auth required pam_nologin.so no_warn</programlisting>
<para>The fields are, in order: service name, facility name, <para>The fields are, in order: service name, facility name,
control flag, module name, and module arguments. Any control flag, module name, and module arguments. Any
additional fields are interpreted as additional module additional fields are interpreted as additional module
arguments.</para> arguments.</para>
<para>A separate chain is constructed for each service / <para>A separate chain is constructed for each service /
facility pair, so while the order in which lines for the same facility pair, so while the order in which lines for the
service and facility appear is significant, the order in which same service and facility appear is significant, the order
the individual services and facilities are listed is in which the individual services and facilities are listed
not&mdash;except that entries for the <literal>other</literal> is not. The examples in the original PAM paper grouped
service, which serves as a fall-back, should come last. The configuration lines by facility, and the &solaris; stock
examples in the original PAM paper grouped configuration lines <filename>pam.conf</filename> still does that, but FreeBSD's
by facility, and the &solaris; stock <filename>pam.conf</filename> stock configuration groups configuration lines by service.
still does that, but FreeBSD's stock configuration groups Either way is fine; either way makes equal sense.</para>
configuration lines by service. Either way is fine; either </section>
way makes equal sense.</para>
<para>OpenPAM and Linux-PAM offer an alternate configuration <section id="pam-config-pam.d">
mechanism, where policies are contained in separate files, <title id="pam-config-pam.d.title">The
named for the service they apply to, in <filename>/etc/pam.d</filename> directory</title>
<filename>/etc/pam.d/</filename>, with only four fields
instead of five&mdash;the service name field is omitted. This
is the preferred mechanism in FreeBSD 5.x. 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> <para>OpenPAM and Linux-PAM support an alternate configuration
over <filename>/etc/pam.conf</filename> is that it is possible mechanism, which is the preferred mechanism in FreeBSD. In
to use the same policy for multiple services by linking each this scheme, each policy is contained in a separate file
service name to a same policy file. For instance, to use the bearing the name of the service it applies to. These files
same policy for the <literal>su</literal> and are stored in <filename>/etc/pam.d/</filename>.</para>
<literal>sudo</literal> services, one could do as
follows:</para> <para>These per-service policy files have only four fields
instead of <filename>pam.conf</filename>'s five: the service
name field is omitted. Thus, instead of the sample
<filename>pam.conf</filename> line from the previous
section, one would have the following line in
<filename>/etc/pam.d/login</filename>:</para>
<programlisting>auth required pam_nologin.so no_warn</programlisting>
<para>As a consequence of this simplified syntax, 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> <screen>&prompt.root; <userinput>cd /etc/pam.d</userinput>
&prompt.root; <userinput>ln -s su sudo</userinput></screen> &prompt.root; <userinput>ln -s su sudo</userinput></screen>
<para>This works because the service name is determined from the <para>This works because the service name is determined from
file name rather than specified in the policy file, so the the file name rather than specified in the policy file, so
same file can be used for multiple differently-named the same file can be used for multiple differently-named
services.</para> services.</para>
<para>One other advantage is that third-party software can <para>Since each service's policy is stored in a separate
easily install policies for their services without the need to file, the <filename>pam.d</filename> mechanism also makes it
edit <filename>/etc/pam.conf</filename>. True to the FreeBSD very easy to install additional policies for third-party
tradition, OpenPAM will even look for policy files in software packages.</para>
<filename>/usr/local/etc/pam.d/</filename> if no configuration </section>
for the requested service is present in
<filename>/etc/pam.d/</filename> or
<filename>/etc/pam.conf</filename>.</para>
<para>Finally, whichever configuration mechanism you choose, the <section id="pam-config-file-order">
<quote>magic</quote> policy <literal>other</literal> is used <title id="pam-config-file-order.title">The policy search
as a fall-back for any service that does not have its own order</title>
policy.</para>
<para>As we have seen above, PAM policies can be found in a
number of places. What happens if policies for the same
service exist in multiple places?</para>
<para>It is essential to understand that PAM's configuration
system is centered on chains.<!-- XXX --></para>
</section>
</section> </section>
<section id="pam-config-breakdown"> <section id="pam-config-breakdown">
<title id="pam-config-breakdown.title">Breakdown of a <title id="pam-config-breakdown.title">Breakdown of a
configuration line</title> configuration line</title>
<para>As explained in the <link <para>As explained in the <link linkend="pam-config-file"
linkend="pam-config-file-locations" endterm="pam-config-file.title"></link> section, each line in
endterm="pam-config-file-locations.title"></link> section, <filename>/etc/pam.conf</filename> consists of four or more
each line in <filename>/etc/pam.conf</filename> consists of fields: the service name, the facility name, the control flag,
four or more fields: the service name, the facility name, the the module name, and zero or more module arguments.</para>
control flag, the module name, and zero or more module
arguments.</para>
<para>The service name is generally (though not always) the name <para>The service name is generally (though not always) the name
of the application the statement applies to. If you are of the application the statement applies to. If you are
@ -996,12 +1010,6 @@ sshd password required pam_permit.so</programlisting>
time which mounts the user's home directory.</para> time which mounts the user's home directory.</para>
</section> </section>
<section id="pam-modules-ftp">
<title id="pam-modules-ftp.title">&man.pam.ftp.8;</title>
<para>The &man.pam.ftp.8; module</para>
</section>
<section id="pam-modules-ftpusers"> <section id="pam-modules-ftpusers">
<title id="pam-modules-ftpusers.title">&man.pam.ftpusers.8;</title> <title id="pam-modules-ftpusers.title">&man.pam.ftpusers.8;</title>
@ -1019,6 +1027,17 @@ sshd password required pam_permit.so</programlisting>
certain groups of users from a particular service.</para> certain groups of users from a particular service.</para>
</section> </section>
<section id="pam-modules-guest">
<title id="pam-modules-guest.title">&man.pam.guest.8;</title>
<para>The &man.pam.guest.8; module allows guest logins using
fixed login names. Various requirements can be placed on the
password, but the default behaviour is to allow any password
as long as the login name is that of a guest account. The
&man.pam.guest.8; module can easily be used to implement
anonymous FTP logins.</para>
</section>
<section id="pam-modules-krb5"> <section id="pam-modules-krb5">
<title id="pam-modules-krb5.title">&man.pam.krb5.8;</title> <title id="pam-modules-krb5.title">&man.pam.krb5.8;</title>
@ -1040,13 +1059,19 @@ sshd password required pam_permit.so</programlisting>
<section id="pam-modules-login-access"> <section id="pam-modules-login-access">
<title id="pam-modules-login-access.title">&man.pam.login.access.8;</title> <title id="pam-modules-login-access.title">&man.pam.login.access.8;</title>
<para>The &man.pam.login.access.8; module</para> <para>The &man.pam.login.access.8; module provides an
implementation of the account management primitive which
enforces the login restrictions specified in the
&man.login.access.5; table.</para>
</section> </section>
<section id="pam-modules-nologin"> <section id="pam-modules-nologin">
<title id="pam-modules-nologin.title">&man.pam.nologin.8;</title> <title id="pam-modules-nologin.title">&man.pam.nologin.8;</title>
<para>The &man.pam.nologin.8; module</para> <para>The &man.pam.nologin.8; module refuses non-root logins
when <filename>/var/run/nologin</filename> exists. This file
is normally created by &man.shutdown.8; when less than five
minutes remain until the scheduled shutdown time.</para>
</section> </section>
<section id="pam-modules-opie"> <section id="pam-modules-opie">
@ -1139,7 +1164,16 @@ sshd password required pam_permit.so</programlisting>
<section id="pam-modules-ssh"> <section id="pam-modules-ssh">
<title id="pam-modules-ssh.title">&man.pam.ssh.8;</title> <title id="pam-modules-ssh.title">&man.pam.ssh.8;</title>
<para>The &man.pam.ssh.8; module</para> <para>The &man.pam.ssh.8; module provides both authentication
and session services. The authentication service allows users
who have passphrase-protected SSH secret keys in their
<filename>~/.ssh</filename> directory to authenticate
themselves by typing their passphrase. The session service
starts &man.ssh-agent.1; and preloads it with the keys that
were decrypted in the authentication phase. This feature is
particularly useful for local logins, whether in X (using
&man.xdm.1; or another PAM-aware X login manager) or at the
console.</para>
</section> </section>
<section id="pam-modules-tacplus"> <section id="pam-modules-tacplus">