|Summary:||[RFE] Teach GSSD to use DIR:/run/user/$UID for Kerberos DIR caches|
|Product:||[Fedora] Fedora||Reporter:||Stephen Gallagher <sgallagh>|
|Component:||nfs-utils||Assignee:||Steve Dickson <steved>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||bfields, jlayton, nalin, steved|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-09-17 22:33:22 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Stephen Gallagher 2012-06-18 12:07:11 UTC
Description of problem: As part of the Fedora 18 Feature https://fedoraproject.org/wiki/Features/KRB5DirCache, GSSD needs to be taught about the new standard location for credential caches. Beginning with Fedora 18, we will now be storing credential caches in the new DIR format added in MIT Kerberos 1.10. This allows us to store multiple TGTs for different realms simultaneously. Additionally, Fedora has adopted a new standard location of /run/user/UID/ccdir for this storage. This will reduce the need for trolling /tmp for credential caches owned by the user, as it can be assumed that for most situations, the cache location will be well-known. Version-Release number of selected component (if applicable): nfs-utils-1.2.6-5.fc18 How reproducible: N/A Expected results: GSSD and any other necessary NFS utilities will attempt to use DIR:/run/user/UID/ccdir as the default cache location. (Substituting UID for the actual numeric value, of course). Additional info:  It is possible for this default location to be changed by an administrator, but we make the assumption that if they do so, they know what they are doing and will deal with other issues that arise from it.
Comment 1 Stephen Gallagher 2012-06-18 14:27:38 UTC
For the record, this can be tested by using sssd-1.9.0-6.fc18.beta2 or later for krb5 login. That will put the credential cache in the proper place by default.
Comment 2 Stephen Gallagher 2012-08-07 19:20:54 UTC
From an IRC conversation today: (02:30:26 PM) sgallagh: steved: At the start of gssd_setup_krb5_user_gss_ccache(), check whether the file /run/user/UID/ccdir/primary exists (02:31:39 PM) sgallagh: Return the dirent for the parent directory (/run/user/UID/ccdir). In gssd_setup_krb5_user_gss_ccache() check whether the path returned from gssd_find_existing_krb5_ccache() is a file or directory. If it's a directory, do the snprintf() with DIR: instead of FILE: (02:31:52 PM) sgallagh: steved: I *think* that's all you will need to do for this to work. (02:32:38 PM) sgallagh: The reason to check for /run/user/UID/ccdir/primary is that all DIR: cache directories must contain a file with this name (it tells libkrb5 where to look). (02:32:54 PM) sgallagh: So that will be enough confirmation that there is a DIR: cache here for gssd to use it.
Comment 3 Nalin Dahyabhai 2012-08-14 23:35:15 UTC
After more discussion, the recommended order is now: * directories under /run/user/$UID matching the pattern "krb5cc*" No "_" is expected because the UID is already a separate component in the pathname, and the "_" was typically there to visually separate the UID from the rest of the filename. * files under /run/user/$UID matching the pattern "krb5cc*" Same reason as above for not including the "_" in the matching pattern. * files under /tmp matching the pattern "krb5cc*" The current default matching prefix ("krb5cc_*") would still work here just as well, but changing it could make the implementation simpler.
Comment 4 Nalin Dahyabhai 2012-08-16 18:07:16 UTC
Created attachment 604985 [details] proposed changes for recognizing "DIR" cache types
Comment 5 Nalin Dahyabhai 2012-08-16 18:09:00 UTC
Created attachment 604986 [details] proposed changes for parameterizing the search path with %U for IDs
Comment 6 Steve Dickson 2012-08-20 13:28:44 UTC
Nalin, Would you mind posting these patches to upstream at email@example.com, tia...
Comment 7 Nalin Dahyabhai 2012-08-20 16:10:14 UTC
Steve, some of the context in these two depends on other patches that are already applied in the package. What's the baseline that versions pitched upstream should be using? Just as important (to me, anyway), do they look correct to you?
Comment 8 Steve Dickson 2012-08-20 17:48:15 UTC
(In reply to comment #7) > Steve, some of the context in these two depends on other patches that are > already applied in the package. What's the baseline that versions pitched > upstream should be using? The upstream tree is at git://linux-nfs.org/~steved/nfs-utils > Just as important (to me, anyway), do they look > correct to you? I took a quick look at them and they look reasonable. I have not done any testing yet, but as long as gssd can fall back to look in legacy places for the cache, I think we are good...
Comment 9 Nalin Dahyabhai 2012-08-21 20:53:31 UTC
Submitted, though I probably should have elaborated more in the patch comments.
Comment 10 Fedora Update System 2012-08-23 18:44:04 UTC
nfs-utils-1.2.6-12.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/nfs-utils-1.2.6-12.fc18
Comment 11 Fedora Update System 2012-08-24 01:23:57 UTC
Package nfs-utils-1.2.6-12.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.6-12.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12618/nfs-utils-1.2.6-12.fc18 then log in and leave karma (feedback).
Comment 12 Fedora Update System 2012-09-17 22:33:22 UTC
nfs-utils-1.2.6-12.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.