ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 2. Authentication with PAM</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.auth.html" title="Part I. Authentication"><link rel="prev" href="part.auth.html" title="Part I. Authentication"><link rel="next" href="cha.nis.html" title="Chapter 3. Using NIS"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.auth.html">Authentication</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Part I. Authentication" href="part.auth.html"><span>◀</span></a> <a accesskey="n" title="Chapter 3. Using NIS" href="cha.nis.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 2. Authentication with PAM"><div class="titlepage"><div><div><h2 class="title"><a name="cha.pam"></a>Chapter 2. Authentication with PAM<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.pam">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.pam.html#sec.security.pam.whatis">2.1. What is PAM?</a></span></dt><dt><span class="sect1"><a href="cha.pam.html#sec.pam.struc.files">2.2. Structure of a PAM Configuration File</a></span></dt><dt><span class="sect1"><a href="cha.pam.html#sec.pam.struc.format">2.3. The PAM Configuration of sshd</a></span></dt><dt><span class="sect1"><a href="cha.pam.html#sec.pam.struc.conf">2.4. Configuration of PAM Modules</a></span></dt><dt><span class="sect1"><a href="cha.pam.html#sec.pam.pam-config">2.5. Configuring PAM Using pam-config</a></span></dt><dt><span class="sect1"><a href="cha.pam.html#sec.pam.info">2.6. For More Information</a></span></dt></dl></div><a class="indexterm" name="idx.Authentifizierung_PAM"></a><a class="indexterm" name="id522939"></a><a class="indexterm" name="idx.PAM"></a><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>
Linux uses PAM (pluggable authentication modules) in the authentication
process as a layer that mediates between user and application. PAM
modules are available on a systemwide basis, so they can be requested by
any application. This chapter describes how the modular authentication
mechanism works and how it is configured.
</p></div><div class="sect1" title="2.1. What is PAM?"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.pam.whatis"></a>2.1. What is PAM?<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.pam.whatis">¶</a></span></h2></div></div></div><p>
System administrators and programmers often want to restrict access to
certain parts of the system or to limit the use of certain functions of
an application. Without PAM, applications must be adapted every time a
new authentication mechanism, such as LDAP, Samba, or Kerberos, is
introduced. This process, however, is rather time-consuming and
error-prone. One way to avoid these drawbacks is to separate applications
from the authentication mechanism and delegate authentication to
centrally managed modules. Whenever a newly required authentication
scheme is needed, it is sufficient to adapt or write a suitable
<span class="emphasis"><em>PAM module</em></span> for use by the program in question.
</p><p>
The PAM concept consists of:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
<span class="emphasis"><em>PAM modules</em></span> are a set of shared libraries for a
specific authentication mechanism.
</p></li><li class="listitem" style="list-style-type: disc"><p>
A <span class="emphasis"><em>module stack</em></span> consists of one or more PAM
modules.
</p></li><li class="listitem" style="list-style-type: disc"><p>
A PAM-aware <span class="emphasis"><em>service</em></span> which needs authentication by
using a module stack or PAM modules. Usually a service is a familiar
name of the corresponding application, like <span class="command"><strong>login</strong></span> or
<span class="command"><strong>su</strong></span>. The service name <code class="literal">other</code> is a
reserved word for default rules.
</p></li><li class="listitem" style="list-style-type: disc"><p>
The execution of a single PAM module can be influenced by
<span class="emphasis"><em>module arguments</em></span>.
</p></li><li class="listitem" style="list-style-type: disc"><p>
Each <span class="emphasis"><em>result</em></span> of a single PAM module execution is
evaluated. A positive value executes the next PAM module, a negative
value depends on the configuration how to proceed. You can configure it
as <span class="quote">“<span class="quote">no influence, proceed</span>”</span> to <span class="quote">“<span class="quote">terminate
immediately</span>”</span> and anything in between.
</p></li></ul></div></div><div class="sect1" title="2.2. Structure of a PAM Configuration File"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.pam.struc.files"></a>2.2. Structure of a PAM Configuration File<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.struc.files">¶</a></span></h2></div></div></div><p>
PAM can be configured in two ways:
</p><div class="variablelist"><dl><dt><span class="term">File based configuration (<code class="filename">/etc/pam.conf</code>)</span></dt><dd><p>
The configuration of each service is stored in
<code class="filename">/etc/pam.conf</code>. However, for maintenance and
usability reasons, this configuration scheme is not used in
openSUSE.
</p></dd><dt><span class="term">Directory based configuration (<code class="filename">/etc/pam.d/</code>)</span></dt><dd><p>
Every service (or program) that relies on the PAM mechanism has its
own configuration file in the <code class="filename">/etc/pam.d/</code>
directory. For example, the service for
<code class="systemitem">sshd</code> can be found in the
<code class="filename">/etc/pam.d/sshd</code> file.
</p></dd></dl></div><p>
The files under <code class="filename">/etc/pam.d/</code> define the PAM modules
used for authentication. Each file consists of lines, which define a
service, and each line consists of a maximum of four components:
</p><pre class="screen"><em class="replaceable"><code>TYPE</code></em> <em class="replaceable"><code>CONTROL</code></em> <em class="replaceable"><code>MODULE_PATH</code></em> <em class="replaceable"><code>MODULE_ARGS</code></em></pre><p>
The components have the following meaning:
</p><div class="variablelist"><dl><dt><span class="term"><em class="replaceable"><code>TYPE</code></em>
</span></dt><dd><p>
Declares the type of the service. PAM modules are processed as stacks.
Different types of modules have different purposes. For example, one
module checks the password, another verifies the location from which
the system is accessed, and yet another reads user-specific settings.
PAM knows about four different types of modules:
</p><div class="variablelist"><dl><dt><span class="term"><code class="literal">auth</code>
</span></dt><dd><p>
Check the user's authenticity, traditionally by querying a password.
However, this can also be achieved with the help of a chip card or
through biometrics (for example, fingerprints or iris scan).
</p></dd><dt><span class="term"><code class="literal">account</code>
</span></dt><dd><p>
Modules of this type check if the user has general permission to
use the requested service. As an example, such a check should be
performed to ensure that no one can log in with the username of an
expired account.
</p></dd><dt><span class="term"><code class="literal">password</code>
</span></dt><dd><p>
The purpose of this type of module is to enable the change of an
authentication token. In most cases, this is a password.
</p></dd><dt><span class="term"><code class="literal">session</code>
</span></dt><dd><p>
Modules of this type are responsible for managing and configuring
user sessions. They are started before and after authentication to
log login attempts and configure the user's specific environment
(mail accounts, home directory, system limits, etc.).
</p></dd></dl></div></dd><dt><span class="term"><em class="replaceable"><code>CONTROL</code></em>
</span></dt><dd><p>
Indicates the behaviour of a PAM module. Each module can have the
following control flags:
</p><div class="variablelist"><dl><dt><span class="term"><code class="literal">required</code>
</span></dt><dd><p>
A module with this flag must be successfully processed before the
authentication may proceed. After the failure of a module with the
<code class="literal">required</code> flag, all other modules with the same
flag are processed before the user receives a message about the
failure of the authentication attempt.
</p></dd><dt><span class="term"><code class="literal">requisite</code>
</span></dt><dd><p>
Modules having this flag must also be processed successfully, in
much the same way as a module with the <code class="literal">required</code>
flag. However, in case of failure a module with this flag gives
immediate feedback to the user and no further modules are
processed. In case of success, other modules are subsequently
processed, just like any modules with the
<code class="literal">required</code> flag. The <code class="literal">requisite</code>
flag can be used as a basic filter checking for the existence of
certain conditions that are essential for a correct authentication.
</p></dd><dt><span class="term"><code class="literal">sufficient</code>
</span></dt><dd><p>
After a module with this flag has been successfully processed, the
requesting application receives an immediate message about the
success and no further modules are processed, provided there was no
preceding failure of a module with the <code class="literal">required</code>
flag. The failure of a module with the
<code class="literal">sufficient</code> flag has no direct consequences, in
the sense that any subsequent modules are processed in their
respective order.
</p></dd><dt><span class="term"><code class="literal">optional</code>
</span></dt><dd><p>
The failure or success of a module with this flag does not have any
direct consequences. This can be useful for modules that are only
intended to display a message (for example, to tell the user that
mail has arrived) without taking any further action.
</p></dd><dt><span class="term"><code class="literal">include</code>
</span></dt><dd><p>
If this flag is given, the file specified as argument is inserted
at this place.
</p></dd></dl></div></dd><dt><span class="term"><em class="replaceable"><code>MODULE_PATH</code></em>
</span></dt><dd><p>
Contains a full filename of a PAM module. It does not need to be
specified explicitly, as long as the module is located in the default
directory <code class="filename">/lib/security</code> (for all 64-bit platforms
supported by openSUSE®, the directory is
<code class="filename">/lib64/security</code>).
</p></dd><dt><span class="term"><em class="replaceable"><code>MODULE_ARGS</code></em>
</span></dt><dd><p>
Contains a space-separated list of options to influence the behaviour
of a PAM module, such as <code class="option">debug</code> (enables debugging) or
<code class="option">nullok</code> (allows the use of empty passwords).
</p></dd></dl></div><p>
In addition, there are global configuration files for PAM modules under
<code class="filename">/etc/security</code>, which define the exact behavior of
these modules (examples include <code class="filename">pam_env.conf</code> and
<code class="filename">time.conf</code>). Every application that uses a PAM module
actually calls a set of PAM functions, which then process the information
in the various configuration files and return the result to the
requesting application.
</p><p>
To facilitate the creation and maintenance of PAM modules, common default
configuration files for the types <code class="literal">auth</code>,
<code class="literal">account</code>, <code class="literal">password</code>, and
<code class="literal">session</code> modules have been introduced. These are
retrieved from every application's PAM configuration. Updates to the
global PAM configuration modules in <code class="filename">common-*</code> are
thus propagated across all PAM configuration files without requiring the
administrator to update every single PAM configuration file.
</p><p>
The global common PAM configuration files are maintained using the
<span class="command"><strong>pam-config</strong></span> tool. This tool automatically adds new
modules to the configuration, changes the configuration of existing ones
or deletes modules (or options) from the configurations. Manual
intervention in maintaining PAM configurations is minimized or no longer
required.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: 64-Bit and 32-Bit Mixed Installations"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">64-Bit and 32-Bit Mixed Installations</th></tr><tr><td colspan="2" align="left" valign="top"><p>
When using a 64-bit operating system, it is possible to also include a
runtime environment for 32-bit applications. In this case, make sure
that you install both versions of the pam modules.
</p></td></tr></table></div></div><div class="sect1" title="2.3. The PAM Configuration of sshd"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.pam.struc.format"></a>2.3. The PAM Configuration of sshd<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.struc.format">¶</a></span></h2></div></div></div><p>
Consider the PAM configuration of sshd as an example:
</p><div class="example"><a name="dat.pam.sshd"></a><p class="title"><b>Example 2.1. PAM Configuration for sshd (<code class="filename">/etc/pam.d/sshd</code>)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.pam.sshd">¶</a></span></p><div class="example-contents"><pre class="screen">#%PAM-1.0 <a name="co.security.pam.sshd.pam-line"></a><img src="callouts/1.png" alt="1" border="0">
auth required pam_nologin.so <a name="co.security.pam.sshd.pam_nologin"></a><img src="callouts/2.png" alt="2" border="0">
auth include common-auth <a name="co.security.pam.sshd.common-auth"></a><img src="callouts/3.png" alt="3" border="0">
account include common-account <a class="xref" href="cha.pam.html#co.security.pam.sshd.common-auth"><img src="callouts/3.png" alt="3" border="0"></a>
password include common-password <a class="xref" href="cha.pam.html#co.security.pam.sshd.common-auth"><img src="callouts/3.png" alt="3" border="0"></a>
session required pam_loginuid.so <a name="co.security.pam.sshd.pam_loginuid"></a><img src="callouts/4.png" alt="4" border="0">
session include common-session <a class="xref" href="cha.pam.html#co.security.pam.sshd.common-auth"><img src="callouts/3.png" alt="3" border="0"></a></pre><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.security.pam.sshd.pam-line"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
Declares the version of this configuration file for PAM 1.0. This is
merely a convention, but could be used in the future to check the
version.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.security.pam.sshd.pam_nologin"><img src="callouts/2.png" alt="2" border="0"></a> </p></td><td valign="top" align="left"><p>
Checks, if <code class="filename">/etc/nologin</code> exists. If it does, no
user other than <code class="systemitem">root</code> may log
in.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.security.pam.sshd.common-auth"><img src="callouts/3.png" alt="3" border="0"></a> </p></td><td valign="top" align="left"><p>
Refers to the configuration files of four module types:
<code class="filename">common-auth</code>, <code class="filename">common-account</code>,
<code class="filename">common-password</code>, and
<code class="filename">common-session</code>. These four files hold the default
configuration for each module type.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.security.pam.sshd.pam_loginuid"><img src="callouts/4.png" alt="4" border="0"></a> </p></td><td valign="top" align="left"><p>
Sets the login uid process attribute for the process that was
authenticated.
</p></td></tr></table></div></div></div><br class="example-break"><p>
By including them instead of adding each module separately to the
respective PAM configuration, you automatically get an updated PAM
configuration when an administrator changes the defaults. Formerly, you
had to adjust all configuration files manually for all applications when
changes to PAM occurred or a new application was installed. Now the PAM
configuration is made with central configuration files and all changes
are automatically inherited by the PAM configuration of each service.
</p><p>
<a class="indexterm" name="id571411"></a> The first include file (<code class="filename">common-auth</code>)
calls three modules of the <code class="literal">auth</code> type:
<code class="systemitem">pam_env.so</code>,
<code class="systemitem">pam_gnome_keyring.so</code> and
<code class="systemitem">pam_unix2.so</code>. See
<a class="xref" href="cha.pam.html#dat.pam.common-auth" title="Example 2.2. Default Configuration for the auth Section">Example 2.2, “Default Configuration for the <code class="literal">auth</code> Section”</a>.
</p><div class="example"><a name="dat.pam.common-auth"></a><p class="title"><b>Example 2.2. Default Configuration for the <code class="literal">auth</code> Section</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.pam.common-auth">¶</a></span></p><div class="example-contents"><pre class="screen">auth required pam_env.so
auth optional pam_gnome_keyring.so
auth required pam_unix2.so</pre></div></div><br class="example-break"><p>
The first one, <code class="systemitem">pam_env.so</code>, loads
<code class="filename">/etc/security/pam_env.conf</code> to set the environment
variables as specified in this file. It can be used to set the
<code class="envar">DISPLAY</code> variable to the correct value, because the
<code class="systemitem">pam_env</code> module knows about the
location from which the login is taking place. The second one
automatically unlocks the GNOME keyring when necessary. The last one,
<code class="systemitem">pam_unix2</code>, checks the user's
login and password against <code class="filename">/etc/passwd</code> and
<code class="filename">/etc/shadow</code>.
</p><p>
The whole stack of <code class="literal">auth</code> modules is processed before
sshd gets any feedback about whether the login has succeeded. Given that
all modules of the stack have the <code class="literal">required</code> control
flag, they must all be processed successfully before sshd receives a
message about the positive result. If one of the modules is not
successful, the entire module stack is still processed and only then is
sshd notified about the negative result.
</p><p>
As soon as all modules of the <code class="literal">auth</code> type have been
successfully processed, another include statement is processed, in this
case, that in <a class="xref" href="cha.pam.html#dat.pam.common-account" title="Example 2.3. Default Configuration for the account Section">Example 2.3, “Default Configuration for the <code class="literal">account</code> Section”</a>.
<code class="filename">common-account</code> contains just one module,
<code class="literal">pam_unix2</code>. If <code class="literal">pam_unix2</code> returns the
result that the user exists, sshd receives a message announcing this
success and the next stack of modules (<code class="literal">password</code>) is
processed, shown in <a class="xref" href="cha.pam.html#dat.pam.common-password" title="Example 2.4. Default Configuration for the password Section">Example 2.4, “Default Configuration for the <code class="literal">password</code> Section”</a>.
</p><div class="example"><a name="dat.pam.common-account"></a><p class="title"><b>Example 2.3. Default Configuration for the <code class="literal">account</code> Section</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.pam.common-account">¶</a></span></p><div class="example-contents"><pre class="screen">account required pam_unix2.so</pre></div></div><br class="example-break"><div class="example"><a name="dat.pam.common-password"></a><p class="title"><b>Example 2.4. Default Configuration for the <code class="literal">password</code> Section</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.pam.common-password">¶</a></span></p><div class="example-contents"><pre class="screen">password requisite pam_pwcheck.so nullok cracklib
password required pam_unix2.so nullok use_authtok</pre></div></div><br class="example-break"><p>
Again, the PAM configuration of sshd involves just an include statement
referring to the default configuration for <code class="literal">password</code>
modules located in <code class="filename">common-password</code>. These modules
must successfully be completed (control flags
<code class="literal">requisite</code> and <code class="literal">required</code>) whenever
the application requests the change of an authentication token.
</p><p>
Changing a password or another authentication token requires a security
check. This is achieved with the <code class="filename">pam_pwcheck</code> module.
The <code class="filename">pam_unix2</code> module used afterwards carries over
any old and new passwords from <code class="filename">pam_pwcheck</code>, so the
user does not need to authenticate again after changing the password.
This procedure makes it impossible to circumvent the checks carried out
by <code class="filename">pam_pwcheck</code>. Whenever the
<code class="literal">account</code> or the <code class="literal">auth</code> type are
configured to complain about expired passwords, the
<code class="literal">password</code> modules should also be used.
</p><div class="example"><a name="dat.pam.common-session"></a><p class="title"><b>Example 2.5. Default Configuration for the <code class="literal">session</code> Section</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.pam.common-session">¶</a></span></p><div class="example-contents"><pre class="screen">session required pam_limits.so
session required pam_unix2.so
session optional pam_umask.so</pre></div></div><br class="example-break"><p>
As the final step, the modules of the <code class="literal">session</code> type
(bundled in the <code class="filename">common-session</code> file) are called to
configure the session according to the settings for the user in question.
The <code class="filename">pam_limits</code> module loads the file
<code class="filename">/etc/security/limits.conf</code>, which may define limits
on the use of certain system resources. The
<code class="filename">pam_unix2</code> module is processed again. The
<code class="filename">pam_umask</code> module can be used to set the file mode
creation mask. Since this module carries the <code class="literal">optional</code>
flag, a failure of this module would not affect the successful completion
of the entire session module stack. The <code class="literal">session</code>
modules are called a second time when the user logs out.
</p></div><div class="sect1" title="2.4. Configuration of PAM Modules"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.pam.struc.conf"></a>2.4. Configuration of PAM Modules<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.struc.conf">¶</a></span></h2></div></div></div><p>
Some of the PAM modules are configurable. The configuration files are
located in <code class="filename">/etc/security</code>. This section briefly
describes the configuration files relevant to the sshd
example—<code class="filename">pam_env.conf</code> and
<code class="filename">limits.conf</code>.
</p><div class="sect2" title="2.4.1. pam_env.conf"><div class="titlepage"><div><div><h3 class="title"><a name="sec.pam.struc.conf.pamenv"></a>2.4.1. pam_env.conf<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.struc.conf.pamenv">¶</a></span></h3></div></div></div><p>
<code class="filename">pam_env.conf</code> can be used to define a standardized
environment for users that is set whenever the
<code class="systemitem">pam_env</code> module is called. With it, preset
environment variables using the following syntax:
</p><pre class="screen"><em class="replaceable"><code>VARIABLE</code></em> [DEFAULT=<em class="replaceable"><code>value</code></em>] [OVERRIDE=<em class="replaceable"><code>value</code></em>]</pre><div class="variablelist"><dl><dt><span class="term"><em class="replaceable"><code>VARIABLE</code></em>
</span></dt><dd><p>
Name of the environment variable to set.
</p></dd><dt><span class="term"><code class="systemitem">[DEFAULT=<value>]</code>
</span></dt><dd><p>
Default <em class="replaceable"><code>value</code></em> the administrator wants to
set.
</p></dd><dt><span class="term"><code class="systemitem">[OVERRIDE=<value>]</code>
</span></dt><dd><p>
Values that may be queried and set by
<code class="systemitem">pam_env</code>, overriding the default value.
</p></dd></dl></div><p>
A typical example of how <code class="systemitem">pam_env</code> can be used is
the adaptation of the <code class="envar">DISPLAY</code> variable, which is changed
whenever a remote login takes place. This is shown in
<a class="xref" href="cha.pam.html#dat.pam.pamenv" title="Example 2.6. pam_env.conf">Example 2.6, “pam_env.conf”</a>.
</p><div class="example"><a name="dat.pam.pamenv"></a><p class="title"><b>Example 2.6. pam_env.conf</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#dat.pam.pamenv">¶</a></span></p><div class="example-contents"><pre class="screen">
REMOTEHOST DEFAULT=localhost OVERRIDE=@{PAM_RHOST}
DISPLAY DEFAULT=${REMOTEHOST}:0.0 OVERRIDE=${DISPLAY}
</pre></div></div><br class="example-break"><p>
The first line sets the value of the <code class="envar">REMOTEHOST</code> variable
to <code class="literal">localhost</code>, which is used whenever
<code class="filename">pam_env</code> cannot determine any other value. The
<code class="envar">DISPLAY</code> variable in turn contains the value of
<code class="envar">REMOTEHOST</code>. Find more information in the comments in
<code class="filename">/etc/security/pam_env.conf</code>.
</p></div><div class="sect2" title="2.4.2. pam_mount.conf"><div class="titlepage"><div><div><h3 class="title"><a name="id319157"></a>2.4.2. pam_mount.conf<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#id319157">¶</a></span></h3></div></div></div><p>
The purpose of <code class="systemitem">pam_mount</code> is to mount user home
directories during the login process, and to unmount them during logout
in an environment where a central file server keeps all the home
directories of users. With this method, it is not necessary to mount a
complete <code class="filename">/home</code> directory where all the user home
directories would be accessible. Instead, only the home directory of the
user who is about to log in, is mounted.
</p><p>
After installing <code class="systemitem">pam_mount</code>, a template of
<code class="filename">pam_mount.conf.xml</code> is available in
<code class="filename">/etc/security</code>. The description of the various
elements can be found in the manual page <span class="command"><strong>man 5
pam_mount.conf</strong></span>.
</p><p>
A basic configuration of this feature can be done with YaST. Select
<span class="guimenu">Network Settings</span>+<span class="guimenu">Windows Domain
Membership</span>+<span class="guimenu">Expert Settings</span> to
add the file server; see Section “Configuring Clients” (Chapter 27, <i>Samba</i>, ↑Reference).
</p></div><div class="sect2" title="2.4.3. limits.conf"><div class="titlepage"><div><div><h3 class="title"><a name="sec.pam.struc.pamlimits"></a>2.4.3. limits.conf<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.struc.pamlimits">¶</a></span></h3></div></div></div><p>
System limits can be set on a user or group basis in
<code class="filename">limits.conf</code>, which is read by the
<code class="systemitem">pam_limits</code> module. The file allows you to set
hard limits, which may not be exceeded at all, and soft limits, which
may be exceeded temporarily. For more information about the syntax and
the options, see the comments in
<code class="filename">/etc/security/limits.conf</code>.
</p></div></div><div class="sect1" title="2.5. Configuring PAM Using pam-config"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.pam.pam-config"></a>2.5. Configuring PAM Using pam-config<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.pam-config">¶</a></span></h2></div></div></div><p>
The <span class="command"><strong>pam-config</strong></span> tool helps you configure the global PAM
configuration files (<code class="filename">/etc/pam.d/common-*-pc</code>) as well
as several selected application configurations. For a list of supported
modules, use the <span class="command"><strong>pam-config --list-modules</strong></span> command.
Use the <span class="command"><strong>pam-config</strong></span> command to maintain your PAM
configuration files. Add new modules to your PAM configurations, delete
other modules or modify options to these modules. When changing global
PAM configuration files, no manual tweaking of the PAM setup for
individual applications is required.
</p><p>
A simple use case for <span class="command"><strong>pam-config</strong></span> involve the
following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p title="Auto-generate a fresh Unix-style PAM configuration."><b>Auto-generate a fresh Unix-style PAM configuration. </b>
Let pam-config create the simplest possible setup which you can extend
later on. The <span class="command"><strong>pam-config --create</strong></span> command creates a
simple UNIX authentication configuration. Pre-existing configuration
files not maintained by pam-config are overwritten, but backup copies
are kept as <code class="literal">*.pam-config-backup</code>.
</p></li><li><p title="Add a new authentication method."><b>Add a new authentication method. </b>
Adding a new authentication method (for example, LDAP) to your stack
of PAM modules comes down to a simple <span class="command"><strong>pam-config --add
--ldap</strong></span> command. LDAP is added wherever appropriate across
all <code class="filename">common-*-pc</code> PAM configuration files.
</p></li><li><p title="Add debugging for test purposes."><b>Add debugging for test purposes. </b>
To make sure the new authentication procedure works as planned, turn
on debugging for all PAM-related operations. The <span class="command"><strong>pam-config
--add --ldap-debug</strong></span> turns on debugging for LDAP-related PAM
operations. Find the debugging output in
<code class="filename">/var/log/messages</code>.
</p></li><li><p title="Query your setup."><b>Query your setup. </b>
Before you finally apply your new PAM setup, check if it contains all
the options you wanted to add. The <span class="command"><strong>pam-config --query
--<em class="replaceable"><code>module</code></em></strong></span> lists both the type and
the options for the queried PAM module.
</p></li><li><p title="Remove the debug options."><b>Remove the debug options. </b>
Finally, remove the debug option from your setup when you are entirely
satisfied with the performance of it. The <span class="command"><strong>pam-config --delete
--ldap-debug</strong></span> command turns of debugging for LDAP
authentication. In case you had debugging options added for other
modules, use similar commands to turn these off.
</p></li></ol></div><p>
When you create your PAM configuration files from scratch using the
<span class="command"><strong>pam-config --create</strong></span> command, it creates symbolic links
from the <code class="filename">common-*</code> to the
<code class="filename">common-*-pc</code> files. pam-config only modifies the
<code class="filename">common-*-pc</code> configuration files. Removing these
symbolic links effectively disable pam-config, because pam-config only
operates on the <code class="filename">common-*-pc</code> files and these files
are not put into effect without the symbolic links.
</p><p>
For more information on the <span class="command"><strong>pam-config</strong></span> command and the
options available, refer to the manual page of
<span class="command"><strong>pam-config(8)</strong></span>.
</p></div><div class="sect1" title="2.6. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.pam.info"></a>2.6. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.pam.info">¶</a></span></h2></div></div></div><p>
In the <code class="filename">/usr/share/doc/packages/pam</code> directory of the
installed system, find the following additional documentation:
</p><div class="variablelist"><dl><dt><span class="term">READMEs</span></dt><dd><p>
In the top level of this directory, there is the general README file.
The subdirectory <code class="filename">modules</code> holds README files about
the available PAM modules.
</p></dd><dt><span class="term">The Linux-PAM System Administrators' Guide</span></dt><dd><p>
This document comprises everything that the system administrator
should know about PAM. It discusses a range of topics, from the syntax
of configuration files to the security aspects of PAM.
</p></dd><dt><span class="term">The Linux-PAM Module Writers' Manual</span></dt><dd><p>
This document summarizes the topic from the developer's point of view,
with information about how to write standard-compliant PAM modules.
</p></dd><dt><span class="term">The Linux-PAM Application Developers' Guide</span></dt><dd><p>
This document comprises everything needed by an application developer
who wants to use the PAM libraries.
</p></dd><dt><span class="term">The PAM Manual Pages</span></dt><dd><p>
PAM in general as well as the individual modules come with manual
pages that provide a good overview of the functionality provided by
the respective component.
</p></dd></dl></div><p>
Thorsten Kukuk has developed a number of PAM modules. Find the
documentation of these modules at
<a class="ulink" href="http://www.suse.de/~kukuk/pam/" target="_top">http://www.suse.de/~kukuk/pam/</a>.
</p><a class="indexterm" name="id573569"></a><a class="indexterm" name="id571975"></a></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.auth.html">Authentication</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Part I. Authentication" href="part.auth.html"><span>◀</span></a> <a accesskey="n" title="Chapter 3. Using NIS" href="cha.nis.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018