Skip Menu |

Subject: gss_acquire_cred_from() and gss_krb5_ccache_name() collection behavior
Date: Sun, 12 Sep 2021 12:11:36 -0400
Ticket 8010 changes the behavior of gss_store_cred() and gss_store_cred_into() to use kinit-like logic to pick a ccache when presented with a collection name, regardless of whether the ccache name is presented via a cred store, gss_krb5_ccache_name(), or the default ccname.

gss_acquire_cred() has used collection logic since ticket 6958 if it uses the default ccname.  But if it is given a ccache collection name via a cred store or gss_krb5_ccache_name() call, it immediately resolves the given name and therefore uses only the collection's primary cache.

Before changing this behavior we should consider the ramifications for behavior Windows (where gss_store_cred() applications are probably unusual but gss_acquire_cred() applications aren't).  While on Unix-like platforms we have migrated towards collection contents being dictated entirely by the default ccname, Windows still presents a collection containing the LSA cache and all API caches.  Therefore, if we simply set the context default ccname to the caller-provided ccache name, on Windows we might still select a cache from an entirely different ccache type.

There are basically four options:

1. Leave gss_acquire_cred() alone (i.e. continue to treat a caller-specified ccache name as determining a single cache, not a collection).

2. Change gss_acquire_cred() to use collection semantics for a caller-specified ccache name and ignore potential problems on Windows.

3. Bring Windows ccache collection behavior in line with the Unix-like platforms, and modify Leash to explicitly enumerate the LSA and API caches rather than rely on finding them via the ccache collection.

4. Add a new collection API for krb5_cc_cache_match() with an added ccname parameter (as described in ) and use it for acquire_cred cache selection.  Ensure that the new API only enumerates the designated collection when one is specified.