** WARNING **
+* Michel D'HOOGE submitted documentation fixes (Bug 408961 - agmorgan)
* fix for module linking directions (Bug 133545 - agmorgan)
* fix for glibc-2.2.2 compilation of pam_issue (Bug 133542 - agmorgan)
* fix pam_userdb to make and link both .o files it needs - converse()
Emmanuel Galanos,
Brad M. Garcia,
Eric Hester,
+Michel D'Hooge,
Roger Hu,
Eric Jacksch,
Michael K. Johnson,
<tag><bf>Recognized arguments:</bf></tag>
<tt/debug/; <tt/conffile=/<em/configuration-file-name/;
-<tt/envfile/=/<em/env-file-name/; <tt/readenv/=/<em/0|1/
+<tt/envfile/=<em/env-file-name/; <tt/readenv/=<em/0|1/
<tag><bf>Description:</bf></tag>
This module allows you to (un)set arbitrary environment variables
<p>
All is controlled via a configuration file (by default,
<tt>/etc/security/pam_env.conf</tt> but can be overriden with
-<tt>connfile</tt> argument). Each line starts with the variable name,
+<tt>conffile</tt> argument). Each line starts with the variable name,
there are then two possible options for each variable <bf>DEFAULT</bf>
-and <bf>OVERRIDE</bf>. <bf>DEFAULT</bf> allows and administrator to
+and <bf>OVERRIDE</bf>. <bf>DEFAULT</bf> allows an administrator to
set the value of the variable to some default value, if none is
supplied then the empty string is assumed. The <bf>OVERRIDE</bf>
option tells pam_env that it should enter in its value (overriding the
embedded or escaped quotes are not supported</bf>.
<p>
-This module can also parse a file with simple KEY=VAL pairs on seperate
-lines (/etc/environment by default). You can change the default file to
-parse, with the <em/envfile/ flag and turn it on or off by setting the
-<em/readenv/ flag to 1 or 0 respectively.
+This module can also parse a file with simple <tt>KEY=VAL</tt> pairs
+on seperate lines (<tt>/etc/environment</tt> by default). You can
+change the default file to parse, with the <em/envfile/ flag and turn
+it on or off by setting the <em/readenv/ flag to 1 or 0 respectively.
<p>
The behavior of this module can be modified with one of the following
<p>
Permitted values for <tt/X/ are <tt/1/ and <tt/2/. These indicate the
-precise time the that filter is to be run. To explain this concept it
-will be useful to have read the Linux-PAM Module developer's
+precise time that the filter is to be run. To understand this concept
+it will be useful to have read the Linux-PAM Module developer's
guide. Basically, for each management group there are up to two ways
of calling the module's functions.
This module intercepts the user's name and password. If the name is
``<tt/ftp/'' or ``<tt/anonymous/'', the user's password is broken up
-at the `<tt/@/' delimiter into a <tt/PAM_RUSER/ and a <tt/PAM_RHOST/
+at the `<tt/@/' delimiter into a <tt/PAM_RUSER/ and a <tt/PAM_RHOST/
part; these pam-items being set accordingly. The username is set to
``<tt/ftp/''. In this case the module succeeds. Alternatively, the
module sets the <tt/PAM_AUTHTOK/ item with the entered password and
</tscreen>
Note, the use of <tt/soft/ and <tt/hard/ limits for the same resource
(see <tt/@faculty/) -- this establishes the <em/default/ and permitted
-<em/extreme/ level of resources that the user can can obtain in a
-given service-session.
+<em/extreme/ level of resources that the user can obtain in a given
+service-session.
<p>
-For the services that need resources limits (login for example) put a
+For the services that need resources limits (login for example) put
the following line in <tt>/etc/pam.conf</tt> as the last line for that
service (usually after the pam_unix session line:
<tscreen>
(counterintuitively) <bf/not/ allowed access to the ftp service.
<p>
-To allow login access only for certain users, you can use an
-pam.conf entry like this:
+To allow login access only for certain users, you can use a
+<tt/pam.conf/ entry like this:
<tscreen>
<verb>
#
<descrip>
<tag><bf>Recognized arguments:</bf></tag>
-<tt/debug/; <tt/dir=/<em/direcory-name/; <tt/nopen/; <tt/close/;
+<tt/debug/; <tt/dir=/<em/directory-name/; <tt/nopen/; <tt/close/;
<tt/noenv/; <tt/empty/; <tt/hash=/<em/hashcount/; <tt/standard/;
<tt/quiet/;
</descrip>
-<sect2>Authentication compent
+<sect2>Authentication component
<p>
Then authentication companent works the same as the session component,
<sect2>Overview of module
<p>
-This module outputs the motd file (<em>/etc/motd</em> by default) upon succesful
-login.
+This module outputs the motd file (<em>/etc/motd</em> by default) upon
+successful login.
<sect2>Session component
<!--
$Id$
- This file was written by Andrew G. Morgan <morgan@linux.kernel.org>
+ This file was written by Andrew G. Morgan <morgan@kernel.org>
-->
<sect1>The Password-Database module
<tag><bf>Author:</bf></tag>
Cristian Gafton <gafton@redhat.com> <newline>
-and Andrew G. Morgan <morgan@linux.kernel.org>
+and Andrew G. Morgan <morgan@kernel.org>
<tag><bf>Maintainer:</bf></tag>
Authors.
<p>
This module is intended to provide the session service for users
-autheticated with a RADIUS server. At the present stage, the only
+authenticated with a RADIUS server. At the present stage, the only
option supported is the use of the RADIUS server as an accounting
server.
<tag><bf>Description:</bf></tag>
This module is intended to provide the session service for users
-autheticated with a RADIUS server. At the present stage, the only
+authenticated with a RADIUS server. At the present stage, the only
option supported is the use of the RADIUS server as an <em/accounting/
server.
<tt>/etc/security/time.conf</tt> configuration file are the following:
<descrip>
-<tag><tt>login ; tty* & ; !ttyp* ; !root ; !Al0000-2400</tt></tag>
+<tag><tt>login ; tty* & !ttyp* ; !root ; !Al0000-2400</tt></tag>
all users except for <tt/root/ are denied access to console-login at
all times.
<tag><bf>Author:</bf></tag>
<tag><bf>Maintainer:</bf></tag>
-Authors.
<tag><bf>Management groups provided:</bf></tag>
account; authentication; password; session
This is the standard Unix authentication module. It uses standard calls
from the system's libraries to retrieve and set account information as
well as authentication. Usually this is obtained from the /etc/passwd
-and the /etc/shadow file aswell if shadow is enabled.
+and the /etc/shadow file as well if shadow is enabled.
<sect2>Account component
$Id$
- Copyright (C) Andrew G. Morgan 1996-9. All rights reserved.
+ Copyright (C) Andrew G. Morgan 1996-2001. All rights reserved.
Redistribution and use in source (sgml) and binary (derived) forms,
with or without modification, are permitted provided that the
<title>The Linux-PAM Application Developers' Guide
<author>Andrew G. Morgan, <tt>morgan@kernel.org</tt>
-<date>DRAFT v0.75 2001/02/04
+<date>DRAFT v0.75 2001/03/18
<abstract>
This manual documents what an application developer needs to know
about the <bf>Linux-PAM</bf> library. It describes how an application
management, credential management, session management and
authentication-token (password changing) management services. It is
important to realize when writing a PAM based application that these
-services are provided in a manner that is <bf>transparent</bf> to the
+services are provided in a manner that is <bf>transparent</bf> to
the application. That is to say, when the application is written, no
assumptions can be made about <em>how</em> the client will be
authenticated.
<p>
Under normal conditions the argument <tt/pam_status/ has the value
-PAM_SUCCESS, but in the event of an unsuccessful service application
-the approprite <bf/Linux-PAM/ error-return value should be used
-here.
-attempt its purpose is to be passed as an argument to the
-module specific function <tt/cleanup()/ (see the <bf/Linux-PAM/
-<htmlurl url="pam_modules.html" name="Module Developers' Guide">).
+PAM_SUCCESS, but in the event of an unsuccessful application for
+service the appropriate <bf/Linux-PAM/ error-return value should be
+used here. Note, <tt/pam_end()/ unconditionally shuts down the
+authentication stack associated with the <tt/pamh/ handle. The value
+taken by <tt/pam_status/ is used as an argument to the module specific
+callback functions, <tt/cleanup()/ (see the <bf/Linux-PAM/ <htmlurl
+url="pam_modules.html" name="Module Developers' Guide">). In this way,
+the module can be given notification of the pass/fail nature of the
+tear-down process, and perform any last minute tasks that are
+appropriate to the module before it is unlinked.
<sect2>Setting PAM items
<label id="pam-set-item-section">
<p>
For applications written with a single thread that are event driven in
-nature, <tt/libpam/ generating this dalay may be undesirable. Instead,
+nature, <tt/libpam/ generating this delay may be undesirable. Instead,
the application may want to register the delay in some other way. For
example, in a single threaded server that serves multiple
authentication requests from a single event loop, the application
as they can update their password.
<tag><tt/PAM_ACCT_EXPIRED/</tag>
- The user is no longer permitted access to the system.
+ The user is no longer permitted to access the system.
<tag><tt/PAM_AUTH_ERR/</tag>
There was an authentication error.
<p>
This function is used to indicate that an authenticated session has
-begun. It is used to inform the module that the user is currently in
+begun. It is used to inform the modules that the user is currently in
a session. It should be possible for the <bf>Linux-PAM</bf> library
to open a session and close the same session (see section <ref
id="pam-close-session-section" name="below">) from different
<p>
This function is used to indicate that an authenticated session has
-ended. It is used to inform the module that the user is exiting a
+ended. It is used to inform the modules that the user is exiting a
session. It should be possible for the <bf>Linux-PAM</bf> library to
open a session and close the same session from different applications.
<p>
-Currently, this function simply calls each of the corresponding
-functions of the loaded modules. The only valid flag is
-<tt/PAM_SILENT/ and this is, of course, <em/optional/.
+This function simply calls each of the corresponding functions of the
+loaded modules in the same order that they were invoked with
+<tt/pam_open_session()/. The only valid flag is <tt/PAM_SILENT/ and
+this is, of course, <em/optional/.
<p>
If any of the <em/required/ loaded modules are unable to close a
<tag>``<tt/NAME/''</tag>
Without an `<tt/=/' the <tt/pam_putenv()/ function will delete the
-correspoding variable from the <bf/Linux-PAM/ environment.
+corresponding variable from the <bf/Linux-PAM/ environment.
</descrip>
<p>
Post Linux-PAM-0.59 (and in the interests of compatibility with
-Sunsoft). The number of resposes is always equal to the <tt/num_msg/
+Sunsoft). The number of responses is always equal to the <tt/num_msg/
conversation function argument. This is slightly easier to program
but does require that the response array is <tt/free(3)/'d after every
call to the conversation function. The index of the responses
<p>
PAM, from the perspective of an application, is a convenient API for
authenticating users. PAM modules generally have no increased
-privilege over that posessed by the application that is making use of
+privilege over that possessed by the application that is making use of
it. For this reason, the application must take ultimate responsibility
for protecting the environment in which PAM operates.
<p>
The point of PAM is that the application is not supposed to have any
-idea how the attatched authentication modules will choose to
+idea how the attached authentication modules will choose to
authenticate the user. So all they can do is provide a conversation
function that will talk directly to the user(client) on the modules'
behalf.
<p>
While it is true that a pop-daemon program is designed with the POP
-protocol in mind and no-one ever considered attatching a retinal
+protocol in mind and no-one ever considered attaching a retinal
scanner to it, it is also the case that the "clean" PAM'ification of
such a daemon would allow for the possibility of a scanner module
-being be attatched to it. The point being that the "standard"
+being be attached to it. The point being that the "standard"
pop-authentication protocol(s) [which will be needed to satisfy
inflexible/legacy clients] would be supported by inserting an
appropriate pam_qpopper module(s). However, having rewritten popd
exchange protocol (prefixes to prompts etc., numbers like 331 in the
case of ftpd) and what is part of the service that the application
delivers. PAM really needs to have total control in the
-authentication "proceedure", the conversation function should only
+authentication "procedure", the conversation function should only
deal with reformatting user prompts and extracting responses from raw
input.
$Id$
- Copyright (c) Andrew G. Morgan 1996-9. All rights reserved.
+ Copyright (c) Andrew G. Morgan 1996-2001. All rights reserved.
Redistribution and use in source (sgml) and binary (derived) forms,
with or without modification, are permitted provided that the
<title>The Linux-PAM System Administrators' Guide
<author>Andrew G. Morgan, <tt>morgan@kernel.org</tt>
-<date>DRAFT v0.75 2001/02/07
+<date>DRAFT v0.75 2001/03/18
<abstract>
This manual documents what a system-administrator needs to know about
the <bf>Linux-PAM</bf> library. It covers the correct syntax of the
identity of the user.
<p>
-Traditinally, the former step is achieved by the <em/login/
+Traditionally, the former step is achieved by the <em/login/
application prompting the user for a password and then verifying that
-it agrees with that located on the system; hence verifying that the
-so far as the system is concerned the user is who they claim to be.
+it agrees with that located on the system; hence verifying that
+as far as the system is concerned the user is who they claim to be.
This is the task that is delegated to <bf/Linux-PAM/.
<p>
center) consults the contents of the PAM configuration file and loads
the modules that are appropriate for application-X. These modules fall
into one of four management groups (lower-center) and are stacked in
-the order they appear in the configuaration file. These modules, when
+the order they appear in the configuration file. These modules, when
called by <bf/Linux-PAM/, perform the various authentication tasks for
the application. Textual information, required from/or offered to the
user, can be exchanged through the use of the application-supplied
</descrip>
<p>
-Any line in (one of) the confiuration file(s), that is not formatted
+Any line in (one of) the configuration file(s), that is not formatted
correctly, will generally tend (erring on the side of caution) to make
the authentication process fail. A corresponding error is written to
the system log files with a call to <tt/syslog(3)/.
projects / linux-pam / commitdiff