Bug 150056 - PAM patches to /bin/su call pam_setcred after pam_open_session
PAM patches to /bin/su call pam_setcred after pam_open_session
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: pam_krb5 (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks: 171175 176344 249301
  Show dependency treegraph
 
Reported: 2005-03-01 18:19 EST by Lamont Granquist
Modified: 2014-01-21 17:51 EST (History)
6 users (show)

See Also:
Fixed In Version: RHEA-2007-0790
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-15 11:12:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lamont Granquist 2005-03-01 18:19:18 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5)
Gecko/20050118

Description of problem:
The manpage for pam_setcred says:

       This  function  is  used to establish, maintain and delete
       the credentials of a user. It should  be  called  after  a
       user has been authenticated and before a session is opened
       for the user (with pam_open_session(3)).

In the PAM patches for /bin/su in sh-utils-2.0.11/12-X, the code looks
like:

static void
run_shell (const char *shell, const char *command, char
**additional_args, const struct passwd *pw)
{
[...]
  retval = pam_open_session(pamh,0);
[...]
  child = fork();
  if (child == 0) {  /* child shell */
    change_identity (pw);
[...]
  }
}
change_identity (const struct passwd *pw)
{
[...]
  retval = pam_setcred(pamh, PAM_ESTABLISH_CRED);
[...]
}

Using pam_krb5 in /etc/pam.d/su will result in pam_open_session being
called twice -- once explicitly and once from the pam_setcred call. 
This will result in the ccache file being deleted, and the KRB5CCNAME
variable pointing at the deleted file, so that klist will not show any
credentials.






Version-Release number of selected component (if applicable):
redhat 7.2 - RHEL4

How reproducible:
Always

Steps to Reproduce:
1. setup kerberos auth on host (/etc/krb5.conf, /etc/krb5.keytab)
2. setup su to use pam_krb5 via /etc/pam.d/su
3. klist after an su will never show any tickets


    

Actual Results:  syslog will show pam_krb5 being called twice from su
(once from the parent pid, once from the child) with the first call
creating the ccfile which klist will be looking for (via the
KRB5CCNAME variable) and once deleting that file and creating another one

Expected Results:  klist should show the correct cached credentials

Additional info:
Comment 1 Lamont Granquist 2005-03-01 19:03:25 EST
confession time:  i haven't tested this bug on RHEL3 yet, its possible
this was fixed by passing in the correct KRB5CCNAME environment
variable.  i've noticed that /bin/login behaves similarly in that it
calls pam_open_session() twice, but it passes the correct KRB5CCNAME
so that klist works.  its possible that a more recent sh-utils works,
i haven't verified.

unfortunately, i don't have a RHEL3 test box which has a keytab file
in the KDC and it'll be awhile before i can check this behavior.
Comment 2 Tim Waugh 2005-04-06 08:02:37 EDT
The /bin/su binary from Red Hat Enterprise Linux 4 comes from the coreutils
package.  However, the coreutils-pam.patch file indeed does not set the
KRB5CCNAME environment variable at all.  I can't see that /bin/login does either
though.
Comment 3 Tomas Mraz 2005-04-06 09:59:13 EDT
Hmm after looking on the pam_krb5 source it does indeed call pam_sm_open_session
from the pam_sm_setcred if PAM_ESTABLISH_CRED is passed to it. But I don't know
how exchanging the calls to pam_setcred and pam_open_session in the
coreutils-pam.patch would help - the pam_sm_open_session from pam_krb5 would be
called twice anyway.
So it seems to me like the fix should be probably done in pam_krb5? (CCing nalin)
However it's true that su should call the pam_setcred(... PAM_ESTABLISH_CRED)
first and then pam_open_session, then it could optionally call pam_setcred(...
PAM_REINITIALIZE_CRED) after changing the uids/gids.
Comment 4 Tim Waugh 2006-05-02 08:03:59 EDT
Seems like this needs to be fixed in krb5 then.
Comment 5 RHEL Product and Program Management 2006-08-18 13:47:57 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 6 Nalin Dahyabhai 2006-09-01 10:39:06 EDT
The crux of the problem here is that su (looking at the current revision for
RHEL 4) is doing this:
  pam_open_session()
  pam_copyenv()
  pam_setcred(PAM_ESTABLISH_CRED)
  fork()

To cope with ill-behaved applications, pam_krb5 creates a new credential cache
and sets KRB5CCNAME when either pam_open_session() or pam_setcred() is called,
so the shell su is spawning gets a value which points to the first ccache which
was created, and then that ccache is destroyed when the second ccache is created
(the creation is done in such a way that the previous ccache is not re-used).

To get the right value to the shell, we can either change su to move the
pam_copyenv() call so that it happens after pam_setcred(), or we can change
pam_krb5 to keep track of two different ccache files.  Longer-term, it's
probably something I'll have to do in pam_krb5 anyway, but short-term, modifying
su seems to be the less-invasive way to go.
Comment 9 RHEL Product and Program Management 2007-04-17 17:28:40 EDT
Although this bugzilla was approved for RHEL 4.5, we were unable
to resolve it in time to be included in the release.  Therefore
it is now proposed for RHEL 4.6.
Comment 10 RHEL Product and Program Management 2007-05-09 07:26:57 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 14 errata-xmlrpc 2007-11-15 11:12:11 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2007-0790.html

Note You need to log in before you can comment on or make changes to this bug.