RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1324486 - pam_sss set KRB5CCNAME with sudo logins
Summary: pam_sss set KRB5CCNAME with sudo logins
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.4
Assignee: SSSD Maintainers
QA Contact: Amith
URL:
Whiteboard:
: 1402591 (view as bug list)
Depends On:
Blocks: 1329378 1402591
TreeView+ depends on / blocked
 
Reported: 2016-04-06 13:00 UTC by Mark
Modified: 2020-05-14 15:09 UTC (History)
8 users (show)

Fixed In Version: sssd-1.15.0-2.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1329378 (view as bug list)
Environment:
Last Closed: 2017-08-01 08:58:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3338 0 None closed pam_sss set KRB5CCNAME with sudo logins 2021-02-17 01:55:17 UTC
Red Hat Product Errata RHEA-2017:2294 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Mark 2016-04-06 13:00:25 UTC 
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:
Comment 2 Jakub Hrozek 2016-04-07 11:20:02 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2296
Comment 3 Jakub Hrozek 2016-04-07 11:46:52 UTC 
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?
Comment 4 Mark 2016-04-08 18:08:47 UTC 
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 ?
Comment 5 Jakub Hrozek 2016-04-09 19:20:40 UTC 
(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.
Comment 6 Mark 2016-04-11 16:57:16 UTC 
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)
Comment 7 Jakub Hrozek 2016-04-11 17:31:02 UTC 
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.
Comment 9 Mark 2016-04-13 21:01:41 UTC 
I'll run my need in 6.something though our account rep or whatever that process is. 


thanks,
Comment 10 Mark 2016-04-13 21:15:01 UTC 
I have no idea why this got set to 7.0 with my comment. setting back to 7.2
Comment 11 Jakub Hrozek 2016-04-14 11:56:47 UTC 
(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.
Comment 12 Jakub Hrozek 2016-11-02 13:15:45 UTC 
Fixed upstream:

master:
 * ce43f710c9638fbbeae077559cd7514370a10c0c
 * c8fe1d922b254aa92e74f428135ada3c8bde87a1
sssd-1-14:
 * 74711db46029415cc9590bb0e3f9cc662dac1d0c
 * 0157678081e299660105c753f2d2ac2081960bca 
sssd-1-13:
 * 5cbea81f6019d4c6acc94b8cec0b955d1767430b
 * 27e38ce07c3f2bb9682e2219ac2ac78e855d43b5
Comment 13 Jakub Hrozek 2016-12-08 08:03:31 UTC 
*** Bug 1402591 has been marked as a duplicate of this bug. ***
Comment 15 Jakub Hrozek 2017-02-03 09:54:36 UTC 
Steps to reproduce: see https://bugzilla.redhat.com/show_bug.cgi?id=1329378#c14
Comment 16 Amith 2017-06-01 13:18:24 UTC 
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 ~]$
Comment 17 errata-xmlrpc 2017-08-01 08:58:07 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.