Bug 1015135 - Unable to fetch credentials from KEYRING: caches
Unable to fetch credentials from KEYRING: caches
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
Depends On:
Blocks: 991187 1016017 1018863
  Show dependency treegraph
Reported: 2013-10-03 09:50 EDT by Jeff Layton
Modified: 2014-06-18 03:43 EDT (History)
6 users (show)

See Also:
Fixed In Version: krb5-1.11.3-22.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-10-14 17:38:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
gsstest test program (4.20 KB, application/octet-stream)
2013-10-03 09:50 EDT, Jeff Layton
no flags Details

  None (edit)
Description Jeff Layton 2013-10-03 09:50:02 EDT
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@POOCHIEREDS.NET 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:

Comment 1 Nalin Dahyabhai 2013-10-03 12:12:36 EDT
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?
Comment 2 Jeff Layton 2013-10-03 12:48:59 EDT
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...
Comment 3 Jeff Layton 2013-10-03 13:10:31 EDT
Yes! krb5-1.11.3-21.fc21 seems to have fixed the issue. Now to test my changes to rpc.gssd...
Comment 4 Jeff Layton 2013-10-03 13:24:35 EDT
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@KEYUTILS_1.4'

...when I updated keyutils packages to the latest release then this worked. Does this mean that keyutils-libs needs an soname bump or something?
Comment 5 Nalin Dahyabhai 2013-10-03 13:56:49 EDT
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.
Comment 6 Nalin Dahyabhai 2013-10-14 16:56:34 EDT
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.
Comment 7 Jeff Layton 2013-10-14 17:19:39 EDT
Sorry, everything seems to be OK now, AFAICT
Comment 8 Nalin Dahyabhai 2013-10-14 17:38:06 EDT
Great to hear.  Marking as closed->rawhide, then.

Note You need to log in before you can comment on or make changes to this bug.