Skip Menu |

From: Jesper Alf <>
Date: Tue, 28 Feb 2017 17:07:50 +0100
Subject: gss_krb5_ccache_name has no effect
Download (untitled) / with headers
text/plain 1.5KiB
We've noticed in our application that calling gss_krb5_ccache_name seems to have no effect. Even after calling that, gss functions still end up using the ccache set in the environment via KRB5CCNAME, and not the one we set with gss_krb5_ccache_name

After spending a bit of time trying to trace the problem, it looks like the issue is with the function
kg_sync_ccache_name in src/lib/gssapi/krb5/gssapi_krb5.c:

Show quoted text
kg_sync_ccache_name (krb5_context context, OM_uint32 *minor_status)
    OM_uint32 err = 0;

     * Sync up the context ccache name with the GSSAPI ccache name.
     * If kg_ccache_name is NULL -- normal unless someone has called
     * gss_krb5_ccache_name() -- then the system default ccache will
     * be picked up and used by resetting the context default ccache.
     * This is needed for platforms which support multiple ccaches.

    if (!err) {
        /* if NULL, resets the context default ccache */
        err = krb5_cc_set_default_name(context,
                                       (char *) k5_getspecific(K5_KEY_GSS_KRB5_CCACHE_NAME));

    *minor_status = err;
    return (*minor_status == 0) ? GSS_S_COMPLETE : GSS_S_FAILURE;

The function never sets err, which means it never calls krb5_cc_set_default_name. I'm not too familiar with the krb5 code, but this looks like a bug to me.

Kind regards,
/ Jesper


Jesper Alf Dam | karoshealth

Software Developer

M: +45 26 15 12 35

Krumtappen 4, 3rd floor

DK-2500 Valby, Denmark

We have automated tests which use gss_krb5_ccache_name(), as well as
some uses of it elsewhere in our tree, so I don't think it's uniformly
broken. Is your program multi-threaded? gss_krb5_ccache_name() sets a
per-thread variable, so it won't have an affect on GSS calls made by
other threads.

In kg_sync_ccache_name(), you are correct that err is never set prior to
the if statement, but the condition is on !err, so it always fires. The
developer who originally wrote that code preferred to use an "if ladder"
style of flow control where all of the mainline code occurs within an
"if no error has occurred yet" conditional. We no longer use that
pattern, but there are traces of it here and there including that