[16786] in Kerberos-V5-bugs
[krbdev.mit.edu #9029] gss_acquire_cred_from() and
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Sun Sep 12 12:11:43 2021
From: "Greg Hudson via RT" <rt-comment@kerborg-prod-app-1.mit.edu>
In-Reply-To:
Message-ID: <rt-4.4.3-2-182396-1631463096-1021.9029-4-0@kerborg-prod-app-1.mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #9029":;
Date: Sun, 12 Sep 2021 12:11:37 -0400
MIME-Version: 1.0
Reply-To: rt-comment@kerborg-prod-app-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Sun Sep 12 12:11:36 2021: Request 9029 was acted upon.
Transaction: Ticket created by ghudson@mit.edu
Queue: krb5
Subject: gss_acquire_cred_from() and gss_krb5_ccache_name() collection
behavior
Owner: Nobody
Requestors: ghudson@mit.edu
Status: new
Ticket <URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9029 >
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.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
