Bug 1018863

+++ 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...