Description of problem: rc.sysinit did not remove stale krb5 tickets used by pam_krb5 and NFS4 (rpcsvcgdd) - files /tmp/rkb5cc_* Version-Release number of selected component (if applicable): initscripts-8.45.17.EL-1 How reproducible: Always if krb5 credentials cache has expired ticket Steps to Reproduce: 1. Configure krb5 support 2. Setup NFS4 ( SECURE_NFS=yes in /etc/sysconfig/nfs ) 3. use kinit to obtain tickets in local credential cache /tmp/krb5cc_<UID> or /tmp/krb5cc_<UID>_<RANDOM> 4. Wait 24 hours to make ticked expired 5. Reboot server 6. try to access NFS4 mount 7. run tail /var/log/message 8. look at message that rpcgssd service can not work with stale Kerberos ticket in /tmp/krb5cc_<UID>_<RANDOM> file, while /tmp/krb5cc_<UID> has correct renewed ticket Actual results: rpcsvcgssd did not allow user to access NFS4 share Expected results: rpcsvcgssd use correct krb5 ticked to allow access Additional info: I suppose that it is not big problem to remove all stale and active caches for users during reboot, because users will be authenticated one more time on login in any case.
Tickets can expire at any time, not just between reboots. I'm not seeing why this is an initscripts issue rather than a rpcsvcgssd issue.
Kevin, Any ideas how this should work? Actually I thought it already did...
Usually, if kerberos ticket is going to expire soon on running system krb5-auth-dialog ask user to enter password to renew ticket. In my situation I have two caches: /tmp/krb5cc_<UID> with valid ticket and /tmp/krb5cc_<UID>_<RANDOM> with expired one. After reboot rpcsvcgssd use cache in file /tmp/krb5cc_<UID>_<RANDOM> with wrong ticket, but kinit use /tmp/krb5cc_<UID> to store valid ticket. So we need to force rpcsvcgssd use correct cache file (or all cache variants) or we need to force deletion stale ticked from caches. Unfortunally I did not familiar with method of naming KRB5 tichet cache files, so I did not see any option to avoid conflict in caches.
(In reply to comment #2) > Kevin, > > Any ideas how this should work? Actually I thought it already did... rpc.gssd has no clue which credentials cache (ccache) to use. Depending on the exact version, it uses name or ownership of the ccache files. If there are multiple matching caches based on name or ownership, gssd tries to use the ccache with the latest mtime. Userland code uses an environment variable (KRB5CCNAME) to determine which ccache to use. (A default name is used if the environment variable is not set.) This information is not available for the kernel to pass up to gssd, so gssd must make an educated guess about which ccache to use. Removing expired ccaches could be a workaround, but as pointed out, it is not something that can just be run at startup since ccaches can expire at any time. I'm not sure of the side-effects of having a daemon running that removes expired credentials caches.
(In reply to comment #3) > Usually, if kerberos ticket is going to expire soon on running system > krb5-auth-dialog ask user to enter password to renew ticket. > > In my situation I have two caches: /tmp/krb5cc_<UID> with valid ticket and > /tmp/krb5cc_<UID>_<RANDOM> with expired one. > > After reboot rpcsvcgssd use cache in file /tmp/krb5cc_<UID>_<RANDOM> with wrong > ticket, but kinit use /tmp/krb5cc_<UID> to store valid ticket. > > So we need to force rpcsvcgssd use correct cache file (or all cache variants) or > we need to force deletion stale ticked from caches. > > Unfortunally I did not familiar with method of naming KRB5 tichet cache files, > so I did not see any option to avoid conflict in caches. If the KRB5CCNAME is not set, /tmp/krb5cc_<UID> is the default name used. Normally KRB5CCNAME is set by the PAM module and/or sshd to add "_<random>". As I noted, this information is not available for the kernel to pass up to gssd, so gssd must use the information it has (only a UID) to try to find credentials to use.
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.
So setting KRB5CCNAME should take care of this issue... So I'm going to close as not a bug... if this is not the case please feel free to reopen this.
*** Bug 431623 has been marked as a duplicate of this bug. ***