os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Try to explain how the dispatcher works, with all (well, both) its quirks.

Browse source 
Translators: still not done, please hold off.

Sponsored by:	DARPA, NAI Labs
This commit is contained in:
Dag-Erling Smørgrav 2002-06-21 16:42:35 +00:00
parent 891f007a38
commit 31444a8de7
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=13449
1 changed files with 87 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

88
en_US.ISO8859-1/articles/pam/article.sgml
View file

@ -834,7 +834,93 @@ sshd password required pam_permit.so</programlisting>
<section id="pam-policies">
<title id="pam-policies.title">Policies</title>
<para><!--XXX-->This section has not yet been written.</para>
<para>To configure PAM correctly, it is essential to understand
how chains are executed.</para>
<para>When an application calls &man.pam.start.3;, the PAM
library loads the configuration for the specified service and
constructs four module chains (one for each facility.) If the
configuration does not specify any modules for one or more
facilities, the configuration for the <literal>other</literal>
service is used instead for these facilities.</para>
<para>When the application later calls one of the six PAM
primitives, the PAM library retrieves the chain for the
corresponding facility and calls the appropriate service
function in each module listed in the chain, in the order in
which they were listed in the configuration. After each call
to a service function, the module type and the error code
returned by the service function are used to determine what
happens next. With a few exceptions, which we will discuss
later, the following table applies:</para>
<table>
<title>PAM chain execution summary</title>
<tgroup cols="4">
<colspec colwidth="1*" colname="type">
<colspec colwidth="1*" colname="success">
<colspec colwidth="1*" colname="ignore">
<colspec colwidth="1*" colname="other">
<thead>
<row>
<entry colname="type"></entry>
<entry colname="success"><literal>PAM_SUCCESS</literal></entry>
<entry colname="ignore"><literal>PAM_IGNORE</literal></entry>
<entry colname="other"><literal>other</literal></entry>
</row>
</thead>
<tbody>
<row>
<entry colname="type">required</entry>
<entry colname="success">-</entry>
<entry colname="ignore">-</entry>
<entry colname="other">fail = true</entry>
</row>
<row>
<entry colname="type">requisite</entry>
<entry colname="success">-</entry>
<entry colname="ignore">-</entry>
<entry colname="other">fail = true, break</entry>
</row>
<row>
<entry colname="type">sufficient</entry>
<entry colname="success">if (!fail) break</entry>
<entry colname="ignore">-</entry>
<entry colname="other">fail = true</entry>
</row>
<row>
<entry colname="type">optional</entry>
<entry colname="success">-</entry>
<entry colname="ignore">-</entry>
<entry colname="other">-</entry>
</row>
</tbody>
</tgroup>
</table>
<para>If <varname>fail</varname> is true at the end of a chain,
or when a <quote>break</quote> is reached, the dispatcher
returns the error code returned by the first module that
failed. Otherwise, it returns
<literal>PAM_SUCCESS</literal>.</para>
<para>The first exception of note is that the error code
<literal>PAM_NEW_AUTHTOK_REQD</literal> is treated like a
success, except that if no module failed, and at least one
module returned <literal>PAM_NEW_AUTHTOK_REQD</literal>, the
dispatcher will return
<literal>PAM_NEW_AUTHTOK_REQD</literal>.</para>
<para>The second exception is that &man.pam.setcred.3; treats
<literal>sufficient</literal> modules as if they were
<literal>required</literal>.</para>
<para>The third and final exception is that
&man.pam.chauthtok.3; runs the entire chain twice (once for
preliminary checks and once to actually set the password), and
in the preliminary phase it treats
<literal>sufficient</literal> modules as if they were
<literal>required</literal>.</para>
</section>
</section>