[16315] in Kerberos-V5-bugs
[krbdev.mit.edu #7707] Credential cache API does not support atomic
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Wed May 29 15:09:57 2019
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: Greg Hudson via RT <rt-comment@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <rt-7707@krbdev.mit.edu>
Message-ID: <rt-7707-49467.17.0673105562381@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #7707'":;
Date: Wed, 29 May 2019 15:09:46 -0400
MIME-Version: 1.0
Reply-To: rt-comment@KRBDEV-PROD-APP-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
In IRC Nico suggested a fifth option, which I think is a little
outside the box but still worth considering. My interpretation is:
5. On krb5_cc_initialize(), do nothing externally visible (or at
least no more visible than creating a temporary file). When the
first non-config credential entry is stored, then atomically replace
the ccache as it is visible to other handles.
There are two caveats to this approach:
A. For this approach to work, the first non-config credential entry
to be stored must be the TGT, or the sole service ticket for non-TGT
ccaches, and important config entries must be written before that
credential is written.
This property is likely already true for creating uses like kinit and
gss_acquire_cred_with_password(). But when the cache is created by a
copy operation, as it is with gss_store_cred_into(), this property
relies on iteration (from the source ccache) preserving order, at
least loosely. Our implementation of the MEMORY ccache type
currently reverses order during iteration; that would need to be
changed, and other ccache types such as KEYRING would need to be
inventoried to determine if they preserve order.
B. This approach does requires the cache to be created via a single
handle, up through storing the first non-cred entry. For example, a
caller who creates a cache, initializes it, closes it, and then
passes the name to some other agent to fill in credentials will no
longer work. A review of known Kerberos applications like kstart
would be indicated to make sure no one does this.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
