From: | ghudson@mit.edu |
To: | rt@kerborg-prod-app-1.mit.edu |
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 https://k5wiki.kerberos.org/wiki/Projects/Credential_cache_collection_improvements#New_collection_architecture ) and use it for acquire_cred cache selection. Ensure that the new API only enumerates the designated collection when one is specified.
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 https://k5wiki.kerberos.org/wiki/Projects/Credential_cache_collection_improvements#New_collection_architecture ) and use it for acquire_cred cache selection. Ensure that the new API only enumerates the designated collection when one is specified.