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

Source string Read only

(itstool) path: listitem/para
Context English State
PAM Essentials
Facilities and Primitives
The PAM API offers six different authentication primitives grouped in four facilities, which are described below.
<literal>auth</literal>
<emphasis>Authentication.</emphasis> This facility concerns itself with authenticating the applicant and establishing the account credentials. It provides two primitives:
<citerefentry><refentrytitle>pam_authenticate</refentrytitle><manvolnum>3</manvolnum></citerefentry> 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.
<citerefentry><refentrytitle>pam_setcred</refentrytitle><manvolnum>3</manvolnum></citerefentry> establishes account credentials such as user ID, group membership and resource limits.
<literal>account</literal>
<emphasis>Account management.</emphasis> This facility handles non-authentication-related issues of account availability, such as access restrictions based on the time of day or the server's work load. It provides a single primitive:
<citerefentry><refentrytitle>pam_acct_mgmt</refentrytitle><manvolnum>3</manvolnum></citerefentry> verifies that the requested account is available.
<literal>session</literal>
<emphasis>Session management.</emphasis> This facility handles tasks associated with session set-up and tear-down, such as login accounting. It provides two primitives:
<citerefentry><refentrytitle>pam_open_session</refentrytitle><manvolnum>3</manvolnum></citerefentry> 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.
<citerefentry><refentrytitle>pam_close_session</refentrytitle><manvolnum>3</manvolnum></citerefentry> 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.
<literal>password</literal>
<emphasis>Password management.</emphasis> This facility is used to change the authentication token associated with an account, either because it has expired or because the user wishes to change it. It provides a single primitive:
<citerefentry><refentrytitle>pam_chauthtok</refentrytitle><manvolnum>3</manvolnum></citerefentry> changes the authentication token, optionally verifying that it is sufficiently hard to guess, has not been used previously, etc.
Modules
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 <trademark class="registered">UNIX</trademark> password database, NIS, LDAP and Radius.
Module Naming
FreeBSD implements each mechanism in a single module, named <literal>pam_<replaceable>mechanism</replaceable>.so</literal> (for instance, <literal>pam_unix.so</literal> for the <trademark class="registered">UNIX</trademark> mechanism.) Other implementations sometimes have separate modules for separate facilities, and include the facility name as well as the mechanism name in the module name. To name one example, <trademark>Solaris</trademark> has a <literal>pam_dial_auth.so.1</literal> module which is commonly used to authenticate dialup users.
Module Versioning
FreeBSD's original PAM implementation, based on Linux-PAM, did not use version numbers for PAM modules. This would commonly cause problems with legacy applications, which might be linked against older versions of the system libraries, as there was no way to load a matching version of the required modules.
OpenPAM, on the other hand, looks for modules that have the same version number as the PAM library (currently 2), and only falls back to an unversioned module if no versioned module could be loaded. Thus legacy modules can be provided for legacy applications, while allowing new (or newly built) applications to take advantage of the most recent modules.
Although <trademark>Solaris</trademark> PAM modules commonly have a version number, they are not truly versioned, because the number is a part of the module name and must be included in the configuration.
Chains and Policies
When a server initiates a PAM transaction, the PAM library tries to load a policy for the service specified in the <citerefentry><refentrytitle>pam_start</refentrytitle><manvolnum>3</manvolnum></citerefentry> 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.
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.
Understanding the control flags is essential to understanding PAM configuration files. There are four different control flags:
<literal>binding</literal>
If the module succeeds and no earlier module in the chain has failed, the chain is immediately terminated and the request is granted. If the module fails, the rest of the chain is executed, but the request is ultimately denied.

Loading…

No matching activity found.

Browse all component changes

Source information

Source string comment
(itstool) path: listitem/para
Flags
read-only
Source string location
article.translate.xml:493
String age
a year ago
Source string age
a year ago
Translation file
articles/pam.pot, string 86