get_cred starting realm

[Nico Williams]

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.

> 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.

> 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.

Nico
--