^^&&^^

Edit File: adg-security-user-identity.html

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>4.4. The identity of the user</title><meta name="generator" content="DocBook XSL Stylesheets V1.78.1"><link rel="home" href="Linux-PAM_ADG.html" title="The Linux-PAM Application Developers' Guide"><link rel="up" href="adg-security.html" title="Chapter 4.  Security issues of Linux-PAM"><link rel="prev" href="adg-security-conv-function.html" title="4.3. The conversation function"><link rel="next" href="adg-security-resources.html" title="4.5. Sufficient resources"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">4.4. The identity of the user</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="adg-security-conv-function.html">Prev</a> </td><th width="60%" align="center">Chapter 4. 
      Security issues of <span class="emphasis"><em>Linux-PAM</em></span>
    </th><td width="20%" align="right"> <a accesskey="n" href="adg-security-resources.html">Next</a></td></tr></table><hr></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="adg-security-user-identity"></a>4.4. The identity of the user</h2></div></div></div><p>
        The <span class="emphasis"><em>Linux-PAM</em></span> 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.
      </p><p>
        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 <span class="emphasis"><em>UID</em></span>
        (user ID) of the running process; the identity of the
        privilege granting user is the <span class="emphasis"><em>EUID</em></span>
        (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 <span class="emphasis"><em>PAM_USER</em></span>
        <span class="citerefentry"><span class="refentrytitle">pam_get_item</span>(3)</span>. Note, modules can change the values of
        <span class="emphasis"><em>PAM_USER</em></span> and <span class="emphasis"><em>PAM_RUSER</em></span>
        during any of the <code class="function">pam_*()</code> library calls.
        For this reason, the application should take care to use the
        <code class="function">pam_get_item()</code> every time it wishes to
        establish who the authenticated user is (or will currently be).
      </p><p>
        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.
      </p><p>
        A more portable solution to storing the identity of the requesting
        user is to use the <span class="emphasis"><em>PAM_RUSER</em></span> <span class="citerefentry"><span class="refentrytitle">pam_get_item</span>(3)</span>. The application should supply this value before
        attempting to authenticate the user with
        <code class="function">pam_authenticate()</code>. 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
        <span class="citerefentry"><span class="refentrytitle">pam_set_item</span>(3)</span> to set <span class="emphasis"><em>PAM_RUSER</em></span>.
      </p><p>
        In addition to the <span class="emphasis"><em>PAM_RUSER</em></span> item, the
        application should supply the <span class="emphasis"><em>PAM_RHOST</em></span>
        (<span class="emphasis"><em>requesting host</em></span>) item. As a general rule,
        the following convention for its value can be assumed:
        NULL = unknown; localhost = invoked directly from the local system;
        <span class="emphasis"><em>other.place.xyz</em></span> = 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.
      </p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="adg-security-conv-function.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="adg-security.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="adg-security-resources.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">4.3. The conversation function </td><td width="20%" align="center"><a accesskey="h" href="Linux-PAM_ADG.html">Home</a></td><td width="40%" align="right" valign="top"> 4.5. Sufficient resources</td></tr></table></div></body></html>