Bug 150056
| Summary: | PAM patches to /bin/su call pam_setcred after pam_open_session | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Lamont Granquist <lamont> |
| Component: | pam_krb5 | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | craig.lawson, jplans, k.georgiou, nalin, tmraz, twaugh |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHEA-2007-0790 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-11-15 16:12:11 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 171175, 176344, 249301 | ||
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. 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. 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. Seems like this needs to be fixed in krb5 then. 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. 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. 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. 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. 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 |
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: