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 1000163 - Klist does not repopulate cached nfs service ticket
Summary: Klist does not repopulate cached nfs service ticket
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: nfs-utils
Version: 6.4
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Steve Dickson
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks: 1438054
TreeView+ depends on / blocked
 
Reported: 2013-08-22 20:31 UTC by Justin Parisi
Modified: 2017-05-22 13:59 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-22 13:59:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Justin Parisi 2013-08-22 20:31:53 UTC 
Description of problem: After getting an initial ticket via NFS Kerberos for an NFS server and then kdestroying or re-running kinit, the NFS service ticket no longer shows up in klist, even though the ticket is still active and allowing access to the mount.

The ticket cache will re-populate after re-mounting.


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

krb5-appl-clients.x86_64               1.0.1-7.el6_2.1                   @base

2.6.32-358.el6.x86_64

How reproducible:

Every time kinit or kdestroy is used


Steps to Reproduce:
1. Mount using krb5 sec
2. Kinit to a user with a valid principal
3. cd to the Kerberized mount
4. Verify the NFS ticket is cached via klist
5. Re-run kinit or run kdestroy and then kinit
6. Verify the NFS ticket is gone
7. cd back into the mount
8. Verify the ticket is still not in klist even though access is allowed

Actual results:

[root@centos64 /]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@centos64 /]# ls /tmp
[root@centos64 /]#

[root@centos64 /]# mount -o sec=krb5 10.61.92.43:/unix /mnt/krb
[root@centos64 /]# ls /tmp
krb5cc_machine_DOMAIN.COM

[root@centos64 /]# su ldapuser
sh-4.1$ klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1107)
sh-4.1$ ls /tmp
krb5cc_machine_DOMAIN.COM

sh-4.1$ kinit
Password for ldapuser:
sh-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1107
Default principal: ldapuser

Valid starting     Expires            Service principal
08/22/13 16:11:51  08/23/13 02:12:27  krbtgt/DOMAIN.COM
        renew until 08/23/13 16:11:51, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96


sh-4.1$ mount | grep krb
10.61.92.43:/unix on /mnt/krb type nfs (rw,sec=krb5,vers=4,addr=10.61.92.43,clientaddr=10.61.179.150)

sh-4.1$ id
uid=1107(ldapuser) gid=503(domain users) groups=503(domain users),10005(testgroup) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

sh-4.1$ cd /mnt/krb
sh-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1107
Default principal: ldapuser

Valid starting     Expires            Service principal
08/22/13 16:11:51  08/23/13 02:12:27  krbtgt/DOMAIN.COM
        renew until 08/23/13 16:11:51, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
08/22/13 16:13:25  08/23/13 02:12:27  nfs/kerberos.domain.com
        renew until 08/23/13 16:11:51, Etype (skey, tkt): des-cbc-crc, des-cbc-md5

sh-4.1$ ls /tmp
krb5cc_1107  krb5cc_machine_DOMAIN.WIN2K8.NETAPP.COM

sh-4.1$ kinit
Password for ldapuser:
sh-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1107
Default principal: ldapuser

Valid starting     Expires            Service principal
08/22/13 16:13:36  08/23/13 02:14:14  krbtgt/DOMAIN.COM
        renew until 08/23/13 16:13:36, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96


sh-4.1$ cd /
sh-4.1$ cd /mnt/krb
sh-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1107
Default principal: ldapuser

Valid starting     Expires            Service principal
08/22/13 16:13:36  08/23/13 02:14:14  krbtgt/DOMAIN.COM
        renew until 08/23/13 16:13:36, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

Even when a different user kinit's, the NFS service ticket is not shown, even though the user can still access the mount:

sh-4.1$ kinit test
Password for test:
sh-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1107
Default principal: test

Valid starting     Expires            Service principal
08/22/13 16:15:45  08/23/13 02:16:22  krbtgt/DOMAIN.COM
        renew until 08/23/13 16:15:45, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

sh-4.1$ cd /
sh-4.1$ cd /mnt/krb
sh-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_1107
Default principal: test

Valid starting     Expires            Service principal
08/22/13 16:15:45  08/23/13 02:16:22  krbtgt/DOMAIN.COM
        renew until 08/23/13 16:15:45, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96


I assume that the client is leveraging the cached ticket on the server.

Expected results:

I would expect the client to recognize that the user has re-authenticated and then re-request the NFS service ticket, or at the very least, re-populate the ticket cache. In Windows, when a user logs out and back in to a system just like kinit would do, or does a klist purge, it re-authenticates via Kerberos and re-requests the CIFS service ticket when accessing CIFS shares and re-populates the cache:

Example:

C:\>klist

Current LogonId is 0:0x257dbf4

Cached Tickets: (7)

#0>     Client: administrator @ DOMAIN.COM
        Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
        Start Time: 8/22/2013 16:24:07 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#1>     Client: administrator @ DOMAIN.COM
        Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 8/22/2013 16:24:05 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#2>     Client: administrator @ DOMAIN.COM
        Server: cifs/cifs.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
        Start Time: 8/22/2013 16:24:24 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)


#3>     Client: administrator @ DOMAIN.COM
        Server: ldap/2K8-DC-1.domain.com @ DOMAIN.WIN2K8.NETAPP.CO
M
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 8/22/2013 16:24:07 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#4>     Client: administrator @ DOMAIN.COM
        Server: LDAP/2K8-DC-1.domain.com/domain.com
@ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 8/22/2013 16:24:07 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#5>     Client: administrator @ DOMAIN.COM
        Server: HOST/2K8-DC-1.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 8/22/2013 16:24:07 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#6>     Client: administrator @ DOMAIN.COM
        Server: cifs/2K8-DC-1.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 8/22/2013 16:24:07 (local)
        End Time:   8/23/2013 2:24:05 (local)
        Renew Time: 8/29/2013 16:24:05 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

C:\>klist purge

Current LogonId is 0:0x257dbf4
        Deleting all tickets:
        Ticket(s) purged!

C:\>klist

Current LogonId is 0:0x257dbf4

Cached Tickets: (0)

C:\>net use \\cifs\ntfs
The command completed successfully.


C:\>klist

Current LogonId is 0:0x257dbf4

Cached Tickets: (4)

#0>     Client: administrator @ DOMAIN.COM
        Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
        Start Time: 8/22/2013 16:29:00 (local)
        End Time:   8/23/2013 2:29:00 (local)
        Renew Time: 8/29/2013 16:29:00 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#1>     Client: administrator @ DOMAIN.COM
        Server: krbtgt/DOMAIN.COM @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
        Start Time: 8/22/2013 16:29:00 (local)
        End Time:   8/23/2013 2:29:00 (local)
        Renew Time: 8/29/2013 16:29:00 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96


#2>     Client: administrator @ DOMAIN.COM
        Server: cifs/cifs.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40a00000 -> forwardable renewable pre_authent
        Start Time: 8/22/2013 16:29:00 (local)
        End Time:   8/23/2013 2:29:00 (local)
        Renew Time: 8/29/2013 16:29:00 (local)
        Session Key Type: RSADSI RC4-HMAC(NT)


#3>     Client: administrator @ DOMAIN.COM
        Server: cifs/2K8-DC-1.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 8/22/2013 16:29:00 (local)
        End Time:   8/23/2013 2:29:00 (local)
        Renew Time: 8/29/2013 16:29:00 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96

Additional info:

I hate to say "be more like Windows," but... :) Caching is nice, but if the cache is emptied, it should be re-populated.
Comment 2 Nalin Dahyabhai 2013-08-22 20:50:19 UTC 
I think this client-side caching of previously-used credentials is something that rpc.gssd controls, though I might be mistaken and it may instead be a function of how the kernel uses it to handle context creation.

Generally, though, so long as already-known credentials are still valid, I'm not personally concerned about picking up newly-acquired creds so long as the new creds are sought out after the previously-used creds expire.

Moving to nfs-utils for now as an initial guess.
Comment 3 RHEL Program Management 2013-10-14 02:36:08 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 5 Steve Dickson 2015-12-14 19:35:17 UTC 
(In reply to Nalin Dahyabhai from comment #2)
> I think this client-side caching of previously-used credentials is something
> that rpc.gssd controls, though I might be mistaken and it may instead be a
> function of how the kernel uses it to handle context creation.
This is a know problem with how the NFS client caches the
creds. Once the original cred is obtained from rpc.gssd, the
kernel cache it until the cred expires.... The user can
even log out and log back in and still use the cached
cred... 

This problem is being worked on upstream atm but its very
unlikely this will be fix in the RHEL6...
Comment 6 Takuma Umeya 2017-05-22 13:59:28 UTC 
Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017.  During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

	http://redhat.com/rhel/lifecycle

This issue does not appear to meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact your EPM to request a re-evaluation of the issue, citing a clear business justification.
Note You need to log in before you can comment on or make changes to this bug.