[19160] in Kerberos_V5_Development
Re: get_cred starting realm
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Apr 29 17:55:02 2015
Message-ID: <5541532B.8070301@mit.edu>
Date: Wed, 29 Apr 2015 17:54:51 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20150429180459.GQ6026@localhost>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On 04/29/2015 02:05 PM, Nico Williams wrote:
>> * The caller asks for one cred to be stored, but the result is that two
>> creds are stored, as observed by the cache type and by future iterations.
>
> Eh, this already happens, no? E.g., with the referral realm business.
Not inside the credential cache layer, no. Those artifacts are created
by a higher layer (get_creds).
>> * If a caller copies a cache by iterating and storing, the cache type
>> for the destination might observe a start realm config entry being
>> stored twice (perhaps with different values), or perhaps only once,
>> depending on the iteration order for the source.
>
> Not if the source implements krb5_cc_remove_cred().
Even if the source implements krb5_cc_remove_cred(). The destination
cache may see one entry synthesized by the generic cache layer when the
local TGT is stored, and another when the start-realm config cred is
explicitly stored. The first value could be wrong, and the destination
cache needs to be able to overwrite it with the second value.
Of course this only happens if the iteration over the source reaches the
local TGT (or a different local TGT!) before reaching the start-realm
config cred.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
