get_cred starting realm

[Benjamin Kaduk]

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.

-Ben