The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: section/para
Context English State
The server obtains various information relating to the transaction (such as the applicant's user name and the name of the host the client runs on) and submits it to PAM using <citerefentry><refentrytitle>pam_set_item</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
The server calls <citerefentry><refentrytitle>pam_authenticate</refentrytitle><manvolnum>3</manvolnum></citerefentry> to authenticate the applicant.
The server calls <citerefentry><refentrytitle>pam_acct_mgmt</refentrytitle><manvolnum>3</manvolnum></citerefentry> to verify that the requested account is available and valid. If the password is correct but has expired, <citerefentry><refentrytitle>pam_acct_mgmt</refentrytitle><manvolnum>3</manvolnum></citerefentry> will return <literal>PAM_NEW_AUTHTOK_REQD</literal> instead of <literal>PAM_SUCCESS</literal>.
If the previous step returned <literal>PAM_NEW_AUTHTOK_REQD</literal>, the server now calls <citerefentry><refentrytitle>pam_chauthtok</refentrytitle><manvolnum>3</manvolnum></citerefentry> to force the client to change the authentication token for the requested account.
Now that the applicant has been properly authenticated, the server calls <citerefentry><refentrytitle>pam_setcred</refentrytitle><manvolnum>3</manvolnum></citerefentry> to establish the credentials of the requested account. It is able to do this because it acts on behalf of the arbitrator, and holds the arbitrator's credentials.
Once the correct credentials have been established, the server calls <citerefentry><refentrytitle>pam_open_session</refentrytitle><manvolnum>3</manvolnum></citerefentry> to set up the session.
The server now performs whatever service the client requested—for instance, provide the applicant with a shell.
Once the server is done serving the client, it calls <citerefentry><refentrytitle>pam_close_session</refentrytitle><manvolnum>3</manvolnum></citerefentry> to tear down the session.
Finally, the server calls <citerefentry><refentrytitle>pam_end</refentrytitle><manvolnum>3</manvolnum></citerefentry> to notify the PAM library that it is done and that it can release whatever resources it has allocated in the course of the transaction.
PAM Configuration
PAM Policy Files
The <filename>/etc/pam.conf</filename>
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:
login auth required no_warn
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.
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. The examples in the original PAM paper grouped configuration lines by facility, and the <trademark>Solaris</trademark> stock <filename>pam.conf</filename> still does that, but FreeBSD's stock configuration groups configuration lines by service. Either way is fine; either way makes equal sense.
The <filename>/etc/pam.d</filename>
OpenPAM and Linux-PAM support an alternate configuration mechanism, which is the preferred mechanism in FreeBSD. In this scheme, each policy is contained in a separate file bearing the name of the service it applies to. These files are stored in <filename>/etc/pam.d/</filename>.
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>:
auth required no_warn
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:
<prompt>#</prompt> <userinput>cd /etc/pam.d</userinput>
<prompt>#</prompt> <userinput>ln -s su sudo</userinput>
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 multiple differently-named services.
Since each service's policy is stored in a separate file, the <filename>pam.d</filename> mechanism also makes it very easy to install additional policies for third-party software packages.
The Policy Search Order
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?
It is essential to understand that PAM's configuration system is centered on chains.
Breakdown of a Configuration Line
As explained in <xref linkend="pam-config-file"/>, each line in <filename>/etc/pam.conf</filename> consists of four or more fields: the service name, the facility name, the control flag, the module name, and zero or more module arguments.
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.
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.


No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: section/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
articles/pam.pot, string 133