"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 <security/pam_appl.h>

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 <security/pam_appl.h>

#include <security/pam_misc.h>

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><security/pam_appl.h></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>

       href="pam_start.xml"/>

       href="pam_end.xml"/>

       href="pam_set_item.xml"/>

       href="pam_get_item.xml"/>

       href="pam_strerror.xml"/>

       href="pam_fail_delay.xml"/>

       href="pam_authenticate.xml"/>

       href="pam_setcred.xml"/>

       href="pam_acct_mgmt.xml"/>

       href="pam_chauthtok.xml"/>

       href="pam_open_session.xml"/>

       href="pam_close_session.xml"/>

       href="pam_putenv.xml"/>

       href="pam_getenv.xml"/>

       href="pam_getenvlist.xml"/>

    </section>

    <section id="adg-interface-of-app-expected">

      <title>What is expected of an application</title>

       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><security/pam_misc.h></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>

       href="pam_misc_conv.xml"/>

       href="pam_misc_paste_env.xml"/>

       href="pam_misc_drop_env.xml"/>

       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>

/*

  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 <kukuk@thkukuk.de>

Copyright (c) 1996-2002 Andrew G. Morgan <morgan@kernel.org>

    </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>