|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012981||CentOS-7||nfs-utils||public||2017-03-16 17:40||2017-03-16 17:40|
|Priority||normal||Severity||major||Reproducibility||have not tried|
|Platform||Intel 64 bit||OS||Centos||OS Version||7|
|Target Version||Fixed in Version|
|Summary||0012981: rpc.gssd not finding credentials in keyring|
|Description||For NFS mounts, rpc.gssd looks for credentials in the primary cache in your KEYRING, and files on /tmp. This makes it difficult for people such as administrators that need to kinit with a principal other than their default one. |
If KRB5CCNAME is set to a /tmp file, "kinit admin" will replace the file with credentials for admin. If rpc.gssd need to check your credentials (e.g. the old ones expired), it will find only credentials for admin, which won't work with your NFS mount.
If KRB5CCNAME is set to KEYRING:persistent:NNN, the default, "kinit admin" will create a new credentials cache, leaving your original one intact. However it has the side effect of making the new credentials cache primary. Again, if rpc.gssd needs to check credentials they will find only credentials for admin, even though your actual credentials are still there.
There are several ways to deal with this, but the cleanest seems to be for rpc.gssd to check for appropriate credentials in your KEYRING, not just the primary. I looked at the implementation. It appears that the specific credentials are not chosen until gssapi inquire is done. The Kerberos implementation of that (with the options used in rpc.gssd) looks only at the primary cache. I believe if a gssapi call that lets you specify a target were used, it would pick the right credentials cache from the keyring.
|Steps To Reproduce||Using an NFS file system, v4, sec=krb5|
1. as root umount (to clear the state)
2. as yourself, kinit as yourself, with KRB5CCNAME=KEYRING:persistent:NNN
3. as root, mount the file system
4. as yourself, cd to your home directory.
This works and you can create files
5. as root, umount the file system. (to clear state)
6. as yourself, in the same session as before, kinit as someone else, e.g. admin.
7. do klist -l to verify that you now have 2 credentials caches, yourself and admin.
8. as root, mount the file system
9. as yourself, cd to your home directory
The cd will probably fail, but even if it works, you won't be able to create files, etc.
|Tags||No tags attached.|
|2017-03-16 17:40||hedrick||New Issue|