+++ This bug was initially created as a clone of Bug #991187 +++ Description of problem: A new, kernel-keyring based credential cache is being added to libkrb5 and used by default in RHEL 7.0. See BZ #991110 and #991148 for full details on the interface. --- Additional comment from Jeff Layton on 2013-10-02 08:14:30 EDT --- In addition to fixing this up, I think this is a good opportunity to fix up some serious warts in the gssd code. For instance... It first tries to use gss_acquire_cred to get credentials. That seems to almost always fail, unless $KRB5CCNAME is set. That makes the initial call to gssd_acquire_user_cred completely useless since it never is set at that point. I'm still trying to understand why that is and am probably going to spin up some separate test programs to try and understand gss_acquire_cred is supposed to work. There's also the problem that it uses setfsuid to switch credentials, which is also useless for handling user keytabs. So, I think we'll need to revert the change to use setfsuid somehow, possibly by turning gssd into a forking program so that the main thread never switches credentials. Looking over this code, it almost seems like a complete rewrite may be in order, but for now I'm planning to just make gssd limp along a little farther. --- Additional comment from Jeff Layton on 2013-10-02 09:36:25 EDT --- Ok, I think I'm starting to get it now. The gssapi libs depend on the real uid being correct. So with my trivial test program, I now get " Credential cache is empty" when the cache has a TGT. Otherwise, I get "Can't find client principal jlayton in cache collection". I suspect that means that I need to be passing in a SPN of some sort, but I haven't quite figured out where yet... --- Additional comment from Stephen Gallagher on 2013-10-02 10:38:06 EDT --- (In reply to Jeff Layton from comment #4) > Ok, I think I'm starting to get it now. The gssapi libs depend on the real > uid being correct. So with my trivial test program, I now get " Credential > cache is empty" when the cache has a TGT. Otherwise, I get "Can't find > client principal jlayton in cache collection". I suspect > that means that I need to be passing in a SPN of some sort, but I haven't > quite figured out where yet... Jeff, there's a bug in the krb5 package right now with the cache collections. Nalin is working on it. We expect to have it fixed hopefully before the week is out and I'll get it into the buildroots immediately. --- Additional comment from Jeff Layton on 2013-10-02 10:48:57 EDT --- Thanks, good to know. I'll hold off until then. Is there a BZ open for that issue? --- Additional comment from Jeff Layton on 2013-10-03 09:52:31 EDT --- I wrote a test program for the problem I was hitting and opened bug 1015135 to track it. Waiting for resolution on that currently. --- Additional comment from Stephen Gallagher on 2013-10-03 10:30:45 EDT --- Thanks, Jeff. No there wasn't a bug open on it yet, because we were expecting to have it fixed before anyone noticed, but it's taking longer than expected. Thanks very much for filing one. --- Additional comment from Jeff Layton on 2013-10-03 11:15:49 EDT --- Ok, a bit more from my "research" here too... For KEYRING: caches we need to switch the *real* (vs. effective or fs) uid of the user in order to access them. But doing that with a single-threaded gssd will allow other local users to kill or renice gssd during that window. So, I think we also need to make gssd fork() when it gets an upcall and have the child do the credential establishment and the downcall. That should also give us a moderately better design anyway since it should parallelize gssd upcalls to some degree. --- Additional comment from Jeff Layton on 2013-10-03 15:57:51 EDT --- Looks like Nalin fixed bug 1015135, so that cleared the way for me to fix gssd. Patches posted here: http://marc.info/?l=linux-nfs&m=138082977121108&w=2 --- Additional comment from Jeff Layton on 2013-10-03 15:59:51 EDT --- Note that this doesn't really parallelize the upcalls since the parent just waits for the child to exit after forking. We could change that, but I'm not sure it's really worth it. --- Additional comment from Simo Sorce on 2013-10-10 11:13:47 EDT --- Here there is a link at how we source the default ccache name to use: https://bugzilla.redhat.com/show_bug.cgi?id=991186#c6 In addition to this we have code in sssd (and now in openssh I believe) to properly expand %{uid} and %{euid}, before passing the ccache name to libkrb5 so that a root process can tell libkrb5 exactly what user cache to use, either by setting exp[licitly KRB5CCNAME or by using the gssapi cred_store extensions etc...
Cloning this bug for Fedora since we need to fix this there first anyway. The patches I have now fix the problem for the most part, but they will likely break things for people using gssproxy. Simo has a plan to change that, but we'll need to coordinate the release of these patches so that it doesn't break things. We may need to add a package conflict between nfs-utils and gssproxy below the fixed version.
Ok, confirmed this by setting up gssd to go through gssproxy and set up a keytab for the unprivileged user. Because it's connecting with euid == 0, this works just fine with the original gssd. With the current patchset I have, that no longer works. So, if we take that set, we'll break people using gssproxy to acquire creds using user keytabs. At this point, I'm not sure how many people that actually means so maybe it's worthwhile not to worry much about breaking that use case?
(In reply to Jeff Layton from comment #2) > Ok, confirmed this by setting up gssd to go through gssproxy and set up a > keytab for the unprivileged user. Because it's connecting with euid == 0, > this works just fine with the original gssd. With the current patchset I > have, that no longer works. > > So, if we take that set, we'll break people using gssproxy to acquire creds > using user keytabs. At this point, I'm not sure how many people that > actually means so maybe it's worthwhile not to worry much about breaking > that use case? Well this was one of the main uses cases to pair rpc.gssd to gssproxy for the client case. That said now that you chage uid most of these installations will simply be able to put the client keytab in /var/kerberos/krb5/user/ unless they also want privilege separation (ie not give access to those keytabs to the users). We still need gssproxy to work correctly for the upcoming constrained delegation case which will perform impersonation using the host keytab. I have preliminary patches for gssproxy here: http://fedorapeople.org/cgit/simo/public_git/gss-proxy.git/log/?h=alluids
Ok, patches are now merged upstream. Probably best to merge these 3 commits: 23118dcce61979da9d3c007cdde1405273de2d8f f9cac65972da588d5218236de60a7be11247a8aa 6b53fc9ce38ba6fff2fd5c2f6ed143747067a39d We probably also want to add a directive like this to the specfile as well: Conflicts: gssproxy < 0.3.0 ...Simo does that look correct?