Hide Forgot
Description of problem: repost of: https://fedorahosted.org/sssd/ticket/2296 because it's affecting a number of my enviroments and I can't find it in RH bugzilla. Applogies if this is a duplicate. " when running sudo -i pam_sss still sets the KRB5CCNAME environment variable of the user that was used for authentication. It should not set the environment variable for sudo cases or should be optionally configurable by the admin. Otherwise with sudo -i root is given the ccache of the user, a kdestroy will wipe the user's ccache and any operation as root may change the ccache permissions or otherwise race with user processes. This is not a security issue as the user ccache is the cache of the originating user, so nothing is really leaked, but it may cause issues and should be fixed. " Version-Release number of selected component (if applicable): How reproducible: 100%. Steps to Reproduce: 1. use pam_sss, login using a password that checks an external source. 2. sudo to another non-root user (e.g. sudo -iu myuser) 3. attempt to kinit Actual results: sudo to another user: [~]$ sudo -iu someprinc kinit -p someprinc Password for someprinc@MITKDC: [someprinc@ash-03-08-vm6 ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_10279_YQSYbA) permissions are still set for the user&&group prior to running sudo. [someprinc@someplace ~]$ ll /tmp/krb5cc_10279_YQSYbA -rw-------. 1 msloan msloan 1438 Apr 6 08:46 /tmp/krb5cc_10279_YQSYbA [someprinc@someplace ~]$ klist klist: Credentials cache permissions incorrect while setting cache flags (ticket cache FILE:/tmp/krb5cc_10279_YQSYbA) the credential cache file will be set incorrectly. and permissions will fail. Expected results: credential cache should be set correctly after sudo'ing ..etc Additional info:
Upstream ticket: https://fedorahosted.org/sssd/ticket/2296
Does just running sudo -i remove the ccache in your test or do you actually need to run kdestroy as root? I can't reproduce the issue, though: [vagrant@centos6 ~]$ su - admin Password: su: warning: cannot change directory to /home/admin: No such file or directory -bash-4.1$ klist Ticket cache: FILE:/tmp/krb5cc_1207000000_4Ng4rz Default principal: admin Valid starting Expires Service principal 04/07/16 11:44:10 04/08/16 11:44:10 krbtgt/IPA.TEST -bash-4.1$ sudo -i [root@centos6 ~]# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) [root@centos6 ~]# logout -bash-4.1$ klist Ticket cache: FILE:/tmp/krb5cc_1207000000_4Ng4rz Default principal: admin Valid starting Expires Service principal 04/07/16 11:44:10 04/08/16 11:44:10 krbtgt/IPA.TEST -bash-4.1$ What am I doing differently than you?
it does not appear that running sudo -i will unset the KRB5CCNAME; as such it remains after sudo -i. I didn't open the upstream ticket, just ran into it while researching my problem and mirrored it over here. perhaps the issue is just that sudo -i won't unset the KRB5CCNAME, then the question is - is the the correct behavior ?
(In reply to Mark from comment #4) > it does not appear that running sudo -i will unset the KRB5CCNAME; as such > it remains after sudo -i. > OK, so you're seeing a different behaviour than I? Note that in my testing KRB5CCNAME was set to /tmp/krb5cc_0 after sudo -i which is what I would expect, because sudo -i opens a login session. > I didn't open the upstream ticket, just ran into it while researching my > problem and mirrored it over here. > Sure, that's fine, thank you. > > perhaps the issue is just that sudo -i won't unset the KRB5CCNAME, then the > question is - is the the correct behavior ? I would expect the correct behaviour to be what I pasted, ie sudo you'd get a new ccache.
when I ssh in and use a password (not a preshared key) I get a TGT for the non default realm on the machine. when I sudo -iu to a different user, the environment KRB5CCNAME is not unset/changed after successful auth and still points to a TGT owned by the original ssh login session. .sudo su - works as expected , KRB5CCNAME is unset with su - ; sudo -iu <user> does not unset it. (for me)
Ah, thank you for the explanation. But given the late stage of RHEL-6, I would prefer bugs to be fixed in RHEL-7 first and then backported on a case-by-case basis.
I'll run my need in 6.something though our account rep or whatever that process is. thanks,
I have no idea why this got set to 7.0 with my comment. setting back to 7.2
(In reply to Mark from comment #9) > I'll run my need in 6.something though our account rep or whatever that > process is. > > > thanks, Yes, please open a case.
Fixed upstream: master: * ce43f710c9638fbbeae077559cd7514370a10c0c * c8fe1d922b254aa92e74f428135ada3c8bde87a1 sssd-1-14: * 74711db46029415cc9590bb0e3f9cc662dac1d0c * 0157678081e299660105c753f2d2ac2081960bca sssd-1-13: * 5cbea81f6019d4c6acc94b8cec0b955d1767430b * 27e38ce07c3f2bb9682e2219ac2ac78e855d43b5
*** Bug 1402591 has been marked as a duplicate of this bug. ***
Steps to reproduce: see https://bugzilla.redhat.com/show_bug.cgi?id=1329378#c14
Verified the bug on SSSD Version: sssd-1.15.2-37.el7.x86_64 Steps followed during verification: 1. Set sudo rule ALL=ALL for an ldap user. See example below: # sudo -l -U testuser Matching Defaults entries for testuser on rhel-74: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR........ User testuser may run the following commands on rhel-74: (ALL) ALL 2. Login as the ldap user. Check the krb ticket and variable KRB5CCNAME. # ssh -l testuser localhost testuser@localhost's password: Last login: Thu Jun 1 18:14:06 2017 from ::1 /usr/bin/id: cannot find name for group ID 21201 $ $ klist Ticket cache: FILE:/tmp/krb5cc_21201_85l8NM Default principal: testuser Valid starting Expires Service principal 2017-06-01T18:19:23 2017-06-02T18:19:22 krbtgt/EXAMPLE.COM renew until 2017-06-01T18:19:23 $ echo $KRB5CCNAME FILE:/tmp/krb5cc_21201_85l8NM 3. Now, run "sudo -iu" and login as another ldap user. Try to list the krb cache and execute kinit. You should see internal credentials cache error. $ sudo -iu testuser1 We trust you have received the usual lecture from the local System Administrator. It usually boils .... .... [sudo] password for testuser: /usr/bin/id: cannot find name for group ID 2121 [testuser1@rhel-74 ~]$ whoami testuser1 [testuser1@rhel-74 ~]$ klist klist: Credentials cache permissions incorrect (filename: /tmp/krb5cc_21201_85l8NM) [testuser1@rhel-74 ~]$ kinit Password for testuser1: kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_21201_85l8NM) while getting initial credentials 4. The new user session retains the KRB5CCNAME value. [testuser1@rhel-74 ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_21201_85l8NM 5. Edit pam section of sssd.conf file and add the following: [pam] pam_response_filter = ENV:KRB5CCNAME:sudo-i 6. Clear sssd cache and restart the service. 7. Repeat the steps-2, 3 and 4. 8. With the latest sssd build, the error disappears while listing the krb cache and the variable KRB5CCNAME is unset. [testuser@rhel-74 ~]$ echo $KRB5CCNAME FILE:/tmp/krb5cc_21201_bJfkL2 [testuser@rhel-74 ~]$ sudo -iu testuser1 [sudo] password for testuser: /usr/bin/id: cannot find name for group ID 2121 [testuser1@rhel-74 ~]$ [testuser1@rhel-74 ~]$ klist klist: No credentials cache found (filename: /tmp/krb5cc_2121) [testuser1@rhel-74 ~]$ whoami testuser1 [testuser1@rhel-74 ~]$ kinit Password for testuser1: [testuser1@rhel-74 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_2121 Default principal: testuser1 Valid starting Expires Service principal 2017-06-01T18:28:23 2017-06-02T18:28:22 krbtgt/EXAMPLE.COM renew until 2017-06-01T18:28:23 [testuser1@rhel-74 ~]$ echo $KRB5CCNAME [testuser1@rhel-74 ~]$
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2017:2294