get_cred starting realm
kaduk at MIT.EDU
Wed Apr 29 13:01:45 EDT 2015
On Wed, 29 Apr 2015, Nico Williams wrote:
> On Wed, Apr 29, 2015 at 10:07:59AM -0400, Greg Hudson wrote:
> > It's clear that the solution to this problem involves changing
> > get_creds, but beyond that there are several choices:
> Not just. Various other functions in Heimdal also needed to get a
> better sense of "starting realm", and my sketch of patches for MIT
> Kerberos shows the same there.
> > 1. We can decide that the creator of a new ccache is responsible for
> > knowing when it is creating one of these edge cases, and signalling that
> > by setting a cache config variable indicating the starting realm.
> > get_creds can check this variable and uses it in preference to the
> > client realm.
"What if the creator of a new FILE: ccache is a java application?"
> > 2. get_creds can iterate through the ccache and use the first local TGT
> > it finds, perhaps after looking up the client realm TGT. This could
> > yield non-deterministic behavior if the ccache type doesn't preserve
> > order, in the rare case where the cache contains multiple local TGT
> > creds. It could also become a performance limiter.
> We know at least one ccache type with non-deterministic iteration order:
> MSLSA. (Though it may not permit insertion.)
The LSA itself permits insertion; our MSLSA interface to it may not be
quite so generous, though I don't remember offhand.
> The Heimdal SQLite3-based ccache uses timestamps for ordering, not
> rowids, and it doesn't have autoincrement, therefore it's deterministic
> for iteration and preserves insertion order IFF time is monotonic.
> Unfortunately it uses seconds since the epoch as its representation of
> time, which means that iteration order for insertions in the same second
> is non-deterministic.
> > 3. We can decide that the ccache layer is responsible for knowing the
> > starting TGT somehow and making that information available to get_creds.
> > Nico's approach in Heimdal falls in the third category, with these
> It's actually (1) and (3). The application, if it knows better, can
> store the ccconfig that names the starting realm, and this will be
> honored, but the ccache layer will pick the first TGT stored as the
> default starting realm until the application tells it otherwise.
This is starting to sound like a reasonable approach.
More information about the krbdev