| Summary: | Klist does not repopulate cached nfs service ticket | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Justin Parisi <parisi> |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED WONTFIX | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4 | CC: | dpal, steved, swhiteho, tumeya |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-05-22 13:59:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 1438054 | ||
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. 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. (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... 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. |
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.