get_cred starting realm

[Simo Sorce]

On Wed, 2015-04-29 at 11:28 -0500, 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.
> > 
> > 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 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.

The KEYRING collection cache order is also probably 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.

+1

> > specifics: if you initialize a ccache handle and then
> > krb5_cc_store_cred() a credential for a local TGT, the generic ccache
> > layer recognizes this and sets a start_realm config variable for the TGT
> > realm.  get_creds checks this variable as in (1).  The implementation,
> > minus some later bugfixes, is at:
> > https://github.com/heimdal/heimdal/commit/629eeb811a411d703fd6c72b7fcab74967c7a762
> 
> Note that the application can also call krb5_cc_set_config() to force a
> different start-realm setting.
> 
> > I am wary of putting this kind of magic into the generic ccache
> > store_creds() dispatch.  I had been assuming that the best solution
> > would be in the first category, but perhaps it is unreasonable to ask
> > ccache creators to do more than store a TGT.  What do other people
> > think?
> 
> It's not magic.  It's a heuristic that a) works for all existing apps,
> b) works for all existing ccaches (that support initialization and
> insertion), c) allows applications to override the heuristic.
> 
> It's no more magic that any of the other ccconfigs we store now, nor
> time offset, and so on.

Having the library take care of it by default and allow applications to
override seem the best compromise between usability and correctness.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York