Bug 1015135

Summary: Unable to fetch credentials from KEYRING: caches
Product: [Fedora] Fedora Reporter: Jeff Layton <jlayton>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dhowells, nalin, nathaniel, sgallagh, ssorce, steved
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: krb5-1.11.3-22.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-14 21:38:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 991187, 1016017, 1018863    
Attachments:
Description Flags
gsstest test program none

Description Jeff Layton 2013-10-03 13:50:02 UTC 
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
Comment 1 Nalin Dahyabhai 2013-10-03 16:12:36 UTC 
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 16:48:59 UTC 
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 17:10:31 UTC 
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 17:24:35 UTC 
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?
Comment 5 Nalin Dahyabhai 2013-10-03 17:56:49 UTC 
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 20:56:34 UTC 
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 21:19:39 UTC 
Sorry, everything seems to be OK now, AFAICT
Comment 8 Nalin Dahyabhai 2013-10-14 21:38:06 UTC 
Great to hear.  Marking as closed->rawhide, then.