2017-03-23 18:19 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0012981CentOS-7nfs-utilspublic2017-03-16 17:40
Reporterhedrick 
PrioritynormalSeveritymajorReproducibilityhave not tried
StatusnewResolutionopen 
PlatformIntel 64 bitOSCentosOS Version7
Product Version7.3.1611 
Target VersionFixed in Version 
Summary0012981: rpc.gssd not finding credentials in keyring
DescriptionFor 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 ReproduceUsing 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.
TagsNo tags attached.
abrt_hash
URL
Attached Files

-Relationships
+Relationships

-Notes
There are no notes attached to this issue.
+Notes

-Issue History
Date Modified Username Field Change
2017-03-16 17:40 hedrick New Issue
+Issue History