summaryrefslogtreecommitdiffstats
path: root/doc/adg/Linux-PAM_ADG.xml
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--doc/adg/Linux-PAM_ADG.xml780
1 files changed, 780 insertions, 0 deletions
diff --git a/doc/adg/Linux-PAM_ADG.xml b/doc/adg/Linux-PAM_ADG.xml
new file mode 100644
index 0000000..79452e1
--- /dev/null
+++ b/doc/adg/Linux-PAM_ADG.xml
@@ -0,0 +1,780 @@
+<?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
+<book id="adg">
+ <bookinfo>
+ <title>The Linux-PAM Application Developers' Guide</title>
+ <authorgroup>
+ <author>
+ <firstname>Andrew G.</firstname>
+ <surname>Morgan</surname>
+ <email>morgan@kernel.org</email>
+ </author>
+ <author>
+ <firstname>Thorsten</firstname>
+ <surname>Kukuk</surname>
+ <email>kukuk@thkukuk.de</email>
+ </author>
+ </authorgroup>
+ <releaseinfo>Version 1.1.2, 31. August 2010</releaseinfo>
+ <abstract>
+ <para>
+ This manual documents what an application developer needs to know
+ about the <emphasis remap='B'>Linux-PAM</emphasis> library. It
+ describes how an application might use the
+ <emphasis remap='B'>Linux-PAM</emphasis> library to authenticate
+ users. In addition it contains a description of the functions
+ to be found in <filename>libpam_misc</filename> library, that can
+ be used in general applications. Finally, it contains some comments
+ on PAM related security issues for the application developer.
+ </para>
+ </abstract>
+ </bookinfo>
+
+ <chapter id="adg-introduction">
+ <title>Introduction</title>
+ <section id="adg-introduction-description">
+ <title>Description</title>
+ <para>
+ <emphasis remap='B'>Linux-PAM</emphasis>
+ (Pluggable Authentication Modules for Linux) is a library that enables
+ the local system administrator to choose how individual applications
+ authenticate users. For an overview of the
+ <emphasis remap='B'>Linux-PAM</emphasis> library see the
+ <emphasis>Linux-PAM System Administrators' Guide</emphasis>.
+ </para>
+ <para>
+ It is the purpose of the <emphasis remap='B'>Linux-PAM</emphasis>
+ project to liberate the development of privilege granting software
+ from the development of secure and appropriate authentication schemes.
+ This is accomplished by providing a documented library of functions
+ that an application may use for all forms of user authentication
+ management. This library dynamically loads locally configured
+ authentication modules that actually perform the authentication tasks.
+ </para>
+ <para>
+ From the perspective of an application developer the information
+ contained in the local configuration of the PAM library should not be
+ important. Indeed it is intended that an application treat the
+ functions documented here as a 'black box' that will deal with all
+ aspects of user authentication. 'All aspects' includes user
+ verification, account management, session initialization/termination
+ and also the resetting of passwords
+ (<emphasis>authentication tokens</emphasis>).
+ </para>
+ </section>
+
+ <section id="adg-introduction-synopsis">
+ <title>Synopsis</title>
+ <para>
+ For general applications that wish to use the services provided by
+ <emphasis remap='B'>Linux-PAM</emphasis> the following is a summary
+ of the relevant linking information:
+ <programlisting>
+#include &lt;security/pam_appl.h&gt;
+
+cc -o application .... -lpam
+ </programlisting>
+ </para>
+ <para>
+ In addition to <command>libpam</command>, there is a library of
+ miscellaneous functions that make the job of writing
+ <emphasis>PAM-aware</emphasis> applications easier (this library is not
+ covered in the DCE-RFC for PAM and is specific to the Linux-PAM
+ distribution):
+ <programlisting>
+#include &lt;security/pam_appl.h&gt;
+#include &lt;security/pam_misc.h&gt;
+
+cc -o application .... -lpam -lpam_misc
+ </programlisting>
+ </para>
+ </section>
+ </chapter>
+
+ <chapter id="adg-overview">
+ <title>Overview</title>
+ <para>
+ Most service-giving applications are restricted. In other words,
+ their service is not available to all and every prospective client.
+ Instead, the applying client must jump through a number of hoops to
+ convince the serving application that they are authorized to obtain
+ service.
+ </para>
+ <para>
+ The process of <emphasis>authenticating</emphasis> a client is what
+ PAM is designed to manage. In addition to authentication, PAM provides
+ account 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
+ <emphasis remap='B'>transparent</emphasis> to the application. That is
+ to say, when the application is written, no assumptions can be made
+ about <emphasis>how</emphasis> the client will be authenticated.
+ </para>
+ <para>
+ The process of authentication is performed by the PAM library via a
+ call to <function>pam_authenticate()</function>. The return value
+ of this function will indicate whether a named client (the
+ <emphasis>user</emphasis>) has been authenticated. If the PAM library
+ needs to prompt the user for any information, such as their
+ <emphasis>name</emphasis> or a <emphasis>password</emphasis>
+ then it will do so. If the PAM library is configured to authenticate
+ the user using some silent protocol, it will do this too. (This
+ latter case might be via some hardware interface for example.)
+ </para>
+ <para>
+ It is important to note that the application must leave all decisions
+ about when to prompt the user at the discretion of the PAM library.
+ </para>
+ <para>
+ The PAM library, however, must work equally well for different styles
+ of application. Some applications, like the familiar
+ <command>login</command> and <command>passwd</command> are terminal
+ based applications, exchanges of information with the client in
+ these cases is as plain text messages. Graphically based applications,
+ however, have a more sophisticated interface. They generally interact
+ with the user via specially constructed dialogue boxes. Additionally,
+ network based services require that text messages exchanged with the
+ client are specially formatted for automated processing: one such
+ example is <command>ftpd</command> which prefixes each exchanged
+ message with a numeric identifier.
+ </para>
+ <para>
+ The presentation of simple requests to a client is thus something very
+ dependent on the protocol that the serving application will use. In
+ spite of the fact that PAM demands that it drives the whole
+ authentication process, it is not possible to leave such protocol
+ subtleties up to the PAM library. To overcome this potential problem,
+ the application provides the PAM library with a
+ <emphasis>conversation</emphasis> function. This function is called
+ from <emphasis>within</emphasis> the PAM library and enables the PAM
+ to directly interact with the client. The sorts of things that this
+ conversation function must be able to do are prompt the user with
+ text and/or obtain textual input from the user for processing by the
+ PAM library. The details of this function are provided in a later
+ section.
+ </para>
+ <para>
+ For example, the conversation function may be called by the PAM
+ library with a request to prompt the user for a password. Its job is
+ to reformat the prompt request into a form that the client will
+ understand. In the case of <command>ftpd</command>, this might involve
+ prefixing the string with the number <command>331</command> and sending
+ the request over the network to a connected client. The conversation
+ function will then obtain any reply and, after extracting the typed
+ password, will return this string of text to the PAM library. Similar
+ concerns need to be addressed in the case of an X-based graphical
+ server.
+ </para>
+ <para>
+ There are a number of issues that need to be addressed when one is
+ porting an existing application to become PAM compliant. A section
+ below has been devoted to this: Porting legacy applications.
+ </para>
+ <para>
+ Besides authentication, PAM provides other forms of management.
+ Session management is provided with calls to
+ <function>pam_open_session()</function> and
+ <function>pam_close_session()</function>. What these functions
+ actually do is up to the local administrator. But typically, they
+ could be used to log entry and exit from the system or for mounting
+ and unmounting the user's home directory. If an application provides
+ continuous service for a period of time, it should probably call
+ these functions, first open after the user is authenticated and then
+ close when the service is terminated.
+ </para>
+ <para>
+ Account management is another area that an application developer
+ should include with a call to <function>pam_acct_mgmt()</function>.
+ This call will perform checks on the good health of the user's account
+ (has it expired etc.). One of the things this function may check is
+ whether the user's authentication token has expired - in such a case the
+ application may choose to attempt to update it with a call to
+ <function>pam_chauthtok()</function>, although some applications
+ are not suited to this task (<command>ftp</command> for example)
+ and in this case the application should deny access to the user.
+ </para>
+ <para>
+ PAM is also capable of setting and deleting the user's credentials with
+ the call <function>pam_setcred()</function>. This function should
+ always be called after the user is authenticated and before service
+ is offered to the user. By convention, this should be the last call
+ to the PAM library before the PAM session is opened. What exactly a
+ credential is, is not well defined. However, some examples are given
+ in the glossary below.
+ </para>
+ </chapter>
+
+ <chapter id="adg-interface">
+ <title>
+ The public interface to <emphasis remap='B'>Linux-PAM</emphasis>
+ </title>
+ <para>
+ Firstly, the relevant include file for the
+ <emphasis remap='B'>Linux-PAM</emphasis> library is
+ <function>&lt;security/pam_appl.h&gt;</function>.
+ It contains the definitions for a number of functions. After
+ listing these functions, we collect some guiding remarks for
+ programmers.
+ </para>
+ <section id="adg-interface-by-app-expected">
+ <title>What can be expected by the application</title>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_start.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_end.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_set_item.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_get_item.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_strerror.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_fail_delay.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_authenticate.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_setcred.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_acct_mgmt.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_chauthtok.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_open_session.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_close_session.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_putenv.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_getenv.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_getenvlist.xml"/>
+ </section>
+ <section id="adg-interface-of-app-expected">
+ <title>What is expected of an application</title>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_conv.xml"/>
+ </section>
+ <section id="adg-interface-programming-notes">
+ <title>Programming notes</title>
+ <para>
+ Note, all of the authentication service function calls accept the
+ token <emphasis remap='B'>PAM_SILENT</emphasis>, which instructs
+ the modules to not send messages to the application. This token
+ can be logically OR'd with any one of the permitted tokens specific
+ to the individual function calls.
+ <emphasis remap='B'>PAM_SILENT</emphasis> does not override the
+ prompting of the user for passwords etc., it only stops informative
+ messages from being generated.
+ </para>
+ </section>
+ </chapter>
+
+ <chapter id="adg-security">
+ <title>
+ Security issues of <emphasis remap='B'>Linux-PAM</emphasis>
+ </title>
+ <para>
+ PAM, from the perspective of an application, is a convenient API for
+ authenticating users. PAM modules generally have no increased
+ 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.
+ </para>
+ <para>
+ A poorly (or maliciously) written application can defeat any
+ <emphasis remap='B'>Linux-PAM</emphasis> module's authentication
+ mechanisms by simply ignoring it's return values. It is the
+ applications task and responsibility to grant privileges and access
+ to services. The <emphasis remap='B'>Linux-PAM</emphasis> library
+ simply assumes the responsibility of <emphasis>authenticating</emphasis>
+ the user; ascertaining that the user <emphasis>is</emphasis> who they
+ say they are. Care should be taken to anticipate all of the documented
+ behavior of the <emphasis remap='B'>Linux-PAM</emphasis> library
+ functions. A failure to do this will most certainly lead to a future
+ security breach.
+ </para>
+
+ <section id="adg-security-library-calls">
+ <title>Care about standard library calls</title>
+ <para>
+ In general, writers of authorization-granting applications should
+ assume that each module is likely to call any or
+ <emphasis>all</emphasis> 'libc' functions. For 'libc' functions
+ that return pointers to static/dynamically allocated structures
+ (ie. the library allocates the memory and the user is not expected
+ to '<function>free()</function>' it) any module call to this
+ function is likely to corrupt a pointer previously
+ obtained by the application. The application programmer should
+ either re-call such a 'libc' function after a call to the
+ <emphasis remap='B'>Linux-PAM</emphasis> library, or copy the
+ structure contents to some safe area of memory before passing
+ control to the <emphasis remap='B'>Linux-PAM</emphasis> library.
+ </para>
+ <para>
+ Two important function classes that fall into this category are
+ <citerefentry>
+ <refentrytitle>getpwnam</refentrytitle><manvolnum>3</manvolnum>
+ </citerefentry> and <citerefentry>
+ <refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum>
+ </citerefentry>.
+ </para>
+ </section>
+
+ <section id="adg-security-service-name">
+ <title>Choice of a service name</title>
+ <para>
+ When picking the <emphasis>service-name</emphasis> that
+ corresponds to the first entry in the
+ <emphasis remap='B'>Linux-PAM</emphasis> configuration file,
+ the application programmer should <emphasis>avoid</emphasis>
+ the temptation of choosing something related to
+ <varname>argv[0]</varname>. It is a trivial matter for any user
+ to invoke any application on a system under a different name and
+ this should not be permitted to cause a security breach.
+ </para>
+ <para>
+ In general, this is always the right advice if the program is
+ setuid, or otherwise more privileged than the user that invokes
+ it. In some cases, avoiding this advice is convenient, but as an
+ author of such an application, you should consider well the ways
+ in which your program will be installed and used. (Its often the
+ case that programs are not intended to be setuid, but end up
+ being installed that way for convenience. If your program falls
+ into this category, don't fall into the trap of making this mistake.)
+ </para>
+ <para>
+ To invoke some <emphasis>target</emphasis> application by
+ another name, the user may symbolically link the target application
+ with the desired name. To be precise all the user need do is,
+ <command>ln -s /target/application ./preferred_name</command>
+ and then run <command>./preferred_name</command>.
+ </para>
+ <para>
+ By studying the <emphasis remap='B'>Linux-PAM</emphasis>
+ configuration file(s), an attacker can choose the
+ <command>preferred_name</command> to be that of a service enjoying
+ minimal protection; for example a game which uses
+ <emphasis remap='B'>Linux-PAM</emphasis> to restrict access to
+ certain hours of the day. If the service-name were to be linked
+ to the filename under which the service was invoked, it
+ is clear that the user is effectively in the position of
+ dictating which authentication scheme the service uses. Needless
+ to say, this is not a secure situation.
+ </para>
+ <para>
+ The conclusion is that the application developer should carefully
+ define the service-name of an application. The safest thing is to
+ make it a single hard-wired name.
+ </para>
+ </section>
+
+ <section id="adg-security-conv-function">
+ <title>The conversation function</title>
+ <para>
+ Care should be taken to ensure that the <function>conv()</function>
+ function is robust. Such a function is provided in the library
+ <command>libpam_misc</command> (see
+ <link linkend="adg-libpam-functions">below</link>).
+ </para>
+ </section>
+
+ <section id="adg-security-user-identity">
+ <title>The identity of the user</title>
+ <para>
+ The <emphasis remap='B'>Linux-PAM</emphasis> modules will need
+ to determine the identity of the user who requests a service,
+ and the identity of the user who grants the service. These two
+ users will seldom be the same. Indeed there is generally a third
+ user identity to be considered, the new (assumed) identity of
+ the user once the service is granted.
+ </para>
+ <para>
+ The need for keeping tabs on these identities is clearly an
+ issue of security. One convention that is actively used by
+ some modules is that the identity of the user requesting a
+ service should be the current <emphasis>UID</emphasis>
+ (user ID) of the running process; the identity of the
+ privilege granting user is the <emphasis>EUID</emphasis>
+ (effective user ID) of the running process; the identity of
+ the user, under whose name the service will be executed, is
+ given by the contents of the <emphasis>PAM_USER</emphasis>
+ <citerefentry>
+ <refentrytitle>pam_get_item</refentrytitle><manvolnum>3</manvolnum>
+ </citerefentry>. Note, modules can change the values of
+ <emphasis>PAM_USER</emphasis> and <emphasis>PAM_RUSER</emphasis>
+ during any of the <function>pam_*()</function> library calls.
+ For this reason, the application should take care to use the
+ <function>pam_get_item()</function> every time it wishes to
+ establish who the authenticated user is (or will currently be).
+ </para>
+ <para>
+ For network-serving databases and other applications that provide
+ their own security model (independent of the OS kernel) the above
+ scheme is insufficient to identify the requesting user.
+ </para>
+ <para>
+ A more portable solution to storing the identity of the requesting
+ user is to use the <emphasis>PAM_RUSER</emphasis> <citerefentry>
+ <refentrytitle>pam_get_item</refentrytitle><manvolnum>3</manvolnum>
+ </citerefentry>. The application should supply this value before
+ attempting to authenticate the user with
+ <function>pam_authenticate()</function>. How well this name can be
+ trusted will ultimately be at the discretion of the local
+ administrator (who configures PAM for your application) and a
+ selected module may attempt to override the value where it can
+ obtain more reliable data. If an application is unable to determine
+ the identity of the requesting entity/user, it should not call
+ <citerefentry>
+ <refentrytitle>pam_set_item</refentrytitle><manvolnum>3</manvolnum>
+ </citerefentry> to set <emphasis>PAM_RUSER</emphasis>.
+ </para>
+ <para>
+ In addition to the <emphasis>PAM_RUSER</emphasis> item, the
+ application should supply the <emphasis>PAM_RHOST</emphasis>
+ (<emphasis>requesting host</emphasis>) item. As a general rule,
+ the following convention for its value can be assumed:
+ NULL = unknown; localhost = invoked directly from the local system;
+ <emphasis>other.place.xyz</emphasis> = some component of the
+ user's connection originates from this remote/requesting host. At
+ present, PAM has no established convention for indicating whether
+ the application supports a trusted path to communication from
+ this host.
+ </para>
+ </section>
+
+ <section id="adg-security-resources">
+ <title>Sufficient resources</title>
+ <para>
+ Care should be taken to ensure that the proper execution of an
+ application is not compromised by a lack of system resources. If an
+ application is unable to open sufficient files to perform its service,
+ it should fail gracefully, or request additional resources.
+ Specifically, the quantities manipulated by the <citerefentry>
+ <refentrytitle>setrlimit</refentrytitle><manvolnum>2</manvolnum>
+ </citerefentry> family of commands should be taken into consideration.
+ </para>
+ <para>
+ This is also true of conversation prompts. The application should not
+ accept prompts of arbitrary length with out checking for resource
+ allocation failure and dealing with such extreme conditions gracefully
+ and in a manner that preserves the PAM API. Such tolerance may be
+ especially important when attempting to track a malicious adversary.
+ </para>
+ </section>
+ </chapter>
+
+ <chapter id='adg-libpam_misc'>
+ <title>A library of miscellaneous helper functions</title>
+ <para>
+ To aid the work of the application developer a library of
+ miscellaneous functions is provided. It is called
+ <command>libpam_misc</command>, and contains a text based
+ conversation function, and routines for enhancing the standard
+ PAM-environment variable support.
+ </para>
+ <para>
+ The functions, structures and macros, made available by this
+ library can be defined by including
+ <function>&lt;security/pam_misc.h&gt;</function>. It should be
+ noted that this library is specific to
+ <emphasis remap='B'>Linux-PAM</emphasis> and is not referred to in
+ the defining DCE-RFC (see <link linkend="adg-see-also">See also</link>)
+ below.
+ </para>
+ <section id='adg-libpam-functions'>
+ <title>Functions supplied</title>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_misc_conv.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_misc_paste_env.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_misc_drop_env.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude"
+ href="pam_misc_setenv.xml"/>
+ </section>
+ </chapter>
+
+ <chapter id='adg-porting'>
+ <title>Porting legacy applications</title>
+ <para>
+ The point of PAM is that the application is not supposed to
+ have any 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.
+ </para>
+ <para>
+ Consider the case that you plug a retinal scanner into the login
+ program. In this situation the user would be prompted: "please look
+ into the scanner". No username or password would be needed - all this
+ information could be deduced from the scan and a database lookup. The
+ point is that the retinal scanner is an ideal task for a "module".
+ </para>
+ <para>
+ While it is true that a pop-daemon program is designed with the POP
+ 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 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
+ <command>popd</command> once in this way any new protocols can be
+ implemented in-situ.
+ </para>
+ <para>
+ One simple test of a ported application would be to insert the
+ <command>pam_permit</command> module and see if the application
+ demands you type a password... In such a case, <command>xlock</command>
+ would fail to lock the terminal - or would at best be a screen-saver,
+ ftp would give password free access to all etc.. Neither of
+ these is a very secure thing to do, but they do illustrate how
+ much flexibility PAM puts in the hands of the local admin.
+ </para>
+ <para>
+ The key issue, in doing things correctly, is identifying what is part
+ of the authentication procedure (how many passwords etc..) the
+ 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 "procedure", the conversation function should only
+ deal with reformatting user prompts and extracting responses from raw
+ input.
+ </para>
+ </chapter>
+
+ <chapter id='adg-glossary'>
+ <title>Glossary of PAM related terms</title>
+ <para>
+ The following are a list of terms used within this document.
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term>Authentication token</term>
+ <listitem>
+ <para>
+ Generally, this is a password. However, a user can authenticate
+ him/herself in a variety of ways. Updating the user's
+ authentication token thus corresponds to
+ <emphasis>refreshing</emphasis> the object they use to
+ authenticate themself with the system. The word password is
+ avoided to keep open the possibility that the authentication
+ involves a retinal scan or other non-textual mode of
+ challenge/response.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Credentials</term>
+ <listitem>
+ <para>
+ Having successfully authenticated the user, PAM is able to
+ establish certain characteristics/attributes of the user.
+ These are termed <emphasis>credentials</emphasis>. Examples
+ of which are group memberships to perform privileged tasks
+ with, and <emphasis>tickets</emphasis> in the form of
+ environment variables etc. . Some user-credentials, such as
+ the user's UID and GID (plus default group memberships) are
+ not deemed to be PAM-credentials. It is the responsibility
+ of the application to grant these directly.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </chapter>
+
+ <chapter id='adg-example'>
+ <title>An example application</title>
+ <para>
+ To get a flavor of the way a <emphasis remap='B'>Linux-PAM</emphasis>
+ application is written we include the following example. It prompts
+ the user for their password and indicates whether their account
+ is valid on the standard output, its return code also indicates
+ the success (<returnvalue>0</returnvalue> for success;
+ <returnvalue>1</returnvalue> for failure).
+ </para>
+ <programlisting><![CDATA[
+/*
+ This program was contributed by Shane Watts
+ [modifications by AGM and kukuk]
+
+ You need to add the following (or equivalent) to the
+ /etc/pam.d/check_user file:
+ # check authorization
+ auth required pam_unix.so
+ account required pam_unix.so
+ */
+
+#include <security/pam_appl.h>
+#include <security/pam_misc.h>
+#include <stdio.h>
+
+static struct pam_conv conv = {
+ misc_conv,
+ NULL
+};
+
+int main(int argc, char *argv[])
+{
+ pam_handle_t *pamh=NULL;
+ int retval;
+ const char *user="nobody";
+
+ if(argc == 2) {
+ user = argv[1];
+ }
+
+ if(argc > 2) {
+ fprintf(stderr, "Usage: check_user [username]\n");
+ exit(1);
+ }
+
+ retval = pam_start("check_user", user, &conv, &pamh);
+
+ if (retval == PAM_SUCCESS)
+ retval = pam_authenticate(pamh, 0); /* is user really user? */
+
+ if (retval == PAM_SUCCESS)
+ retval = pam_acct_mgmt(pamh, 0); /* permitted access? */
+
+ /* This is where we have been authorized or not. */
+
+ if (retval == PAM_SUCCESS) {
+ fprintf(stdout, "Authenticated\n");
+ } else {
+ fprintf(stdout, "Not Authenticated\n");
+ }
+
+ if (pam_end(pamh,retval) != PAM_SUCCESS) { /* close Linux-PAM */
+ pamh = NULL;
+ fprintf(stderr, "check_user: failed to release authenticator\n");
+ exit(1);
+ }
+
+ return ( retval == PAM_SUCCESS ? 0:1 ); /* indicate success */
+}
+]]>
+ </programlisting>
+ </chapter>
+
+ <chapter id='adg-files'>
+ <title>Files</title>
+ <variablelist>
+ <varlistentry>
+ <term><filename>/usr/include/security/pam_appl.h</filename></term>
+ <listitem>
+ <para>
+ Header file with interfaces for
+ <emphasis remap='B'>Linux-PAM</emphasis> applications.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>/usr/include/security/pam_misc.h</filename></term>
+ <listitem>
+ <para>
+ Header file for useful library functions for making
+ applications easier to write.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </chapter>
+
+ <chapter id="adg-see-also">
+ <title>See also</title>
+ <itemizedlist>
+ <listitem>
+ <para>
+ The Linux-PAM System Administrators' Guide.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The Linux-PAM Module Writers' Guide.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The V. Samar and R. Schemers (SunSoft), ``UNIFIED LOGIN WITH
+ PLUGGABLE AUTHENTICATION MODULES'', Open Software Foundation
+ Request For Comments 86.0, October 1995.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </chapter>
+
+ <chapter id='adg-author'>
+ <title>Author/acknowledgments</title>
+ <para>
+ This document was written by Andrew G. Morgan (morgan@kernel.org)
+ with many contributions from
+ Chris Adams, Peter Allgeyer, Tim Baverstock, Tim Berger, Craig S. Bell,
+ Derrick J. Brashear, Ben Buxton, Seth Chaiklin, Oliver Crow, Chris Dent,
+ Marc Ewing, Cristian Gafton, Emmanuel Galanos, Brad M. Garcia,
+ Eric Hester, Roger Hu, Eric Jacksch, Michael K. Johnson, David Kinchlea,
+ Olaf Kirch, Marcin Korzonek, Thorsten Kukuk, Stephen Langasek,
+ Nicolai Langfeldt, Elliot Lee, Luke Kenneth Casson Leighton,
+ Al Longyear, Ingo Luetkebohle, Marek Michalkiewicz, Robert Milkowski,
+ Aleph One, Martin Pool, Sean Reifschneider, Jan Rekorajski, Erik Troan,
+ Theodore Ts'o, Jeff Uphoff, Myles Uyema, Savochkin Andrey Vladimirovich,
+ Ronald Wahl, David Wood, John Wilmes, Joseph S. D. Yao
+ and Alex O. Yuriev.
+ </para>
+ <para>
+ Thanks are also due to Sun Microsystems, especially to Vipin Samar and
+ Charlie Lai for their advice. At an early stage in the development of
+ <emphasis remap='B'>Linux-PAM</emphasis>, Sun graciously made the
+ documentation for their implementation of PAM available. This act
+ greatly accelerated the development of
+ <emphasis remap='B'>Linux-PAM</emphasis>.
+ </para>
+ </chapter>
+
+ <chapter id='adg-copyright'>
+ <title>Copyright information for this document</title>
+ <programlisting>
+Copyright (c) 2006 Thorsten Kukuk &lt;kukuk@thkukuk.de&gt;
+Copyright (c) 1996-2002 Andrew G. Morgan &lt;morgan@kernel.org&gt;
+ </programlisting>
+ <para>
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are
+ met:
+ </para>
+ <programlisting>
+1. Redistributions of source code must retain the above copyright
+ notice, and the entire permission notice in its entirety,
+ including the disclaimer of warranties.
+
+2. Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+3. The name of the author may not be used to endorse or promote
+ products derived from this software without specific prior
+ written permission.
+ </programlisting>
+ <para>
+ Alternatively, this product may be distributed under the terms of
+ the GNU General Public License (GPL), in which case the provisions
+ of the GNU GPL are required instead of the above restrictions.
+ (This clause is necessary due to a potential bad interaction between
+ the GNU GPL and the restrictions contained in a BSD-style copyright.)
+ </para>
+ <programlisting>
+THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
+OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
+TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ </programlisting>
+ </chapter>
+</book>