Created attachment 807090 [details] gsstest test program I've been working on fixing rpc.gssd to work with KEYRING: caches and cleaning out some of the really nasty cruft in that program. (See bug 991187). In the process, I've written this simple test program to figure out whether and how some of the existing gssd code works. Regardless of the type of cache in use, I get this error if I don't have a TGT for the user (which is expected): ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Can't find client principal jlayton in cache collection ...if I then kinit a FILE: or DIR: cache and have krb5.conf set to look for those as the default, then the program exits w/o error. If however, I use a KEYRING: cache, I get this error: # ./gsstest 4447 ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Credential cache is empty I suspect this is a bug in libgssapi_krb5.so, but it could be elsewhere too. I'm using this on a recent rawhide VM to test it: krb5-libs-1.11.3-20.fc21.x86_64
What default_ccache_name setting, specifically, are you using when obtaining creds and attempting to use them? Does the just-built krb5-1.11.3-21.fc21 fare any better?
This one works fine, as does leaving this to the default FILE: cache location: default_ccache_name = DIR:/run/user/%{uid}/krb5cc This is the one that doesn't work: default_ccache_name = KEYRING:persistent:%{uid} I'll test out krb5-1.11.3-21.fc21 and get back to you...
Yes! krb5-1.11.3-21.fc21 seems to have fixed the issue. Now to test my changes to rpc.gssd...
There is one issue with the new packages though. Building nfs-utils against them failed initially: configure:5111: gcc -o conftest -g -O2 conftest.c -ltirpc >&5 /lib64/libkrb5.so.3: undefined reference to `keyctl_get_persistent' ...when I updated keyutils packages to the latest release then this worked. Does this mean that keyutils-libs needs an soname bump or something?
The symbol versioning is supposed to help avoid that, by grouping symbols with a library version (such as KEYUTILS_1.4) as they're added, but I think this one was incorrectly added to a version that existed before the symbol was added, so the krb5 package is going to need to bump its hard-wired version requirement again. Thanks for spotting it.
Jeff, any news here? I'm all set to mark this one as fixed in krb5-1.11.3-22.fc21 if things still look good from where you are.
Sorry, everything seems to be OK now, AFAICT
Great to hear. Marking as closed->rawhide, then.