[19153] in Kerberos_V5_Development
Re: get_cred starting realm
daemon@ATHENA.MIT.EDU (Simo Sorce)
Wed Apr 29 12:52:05 2015
Message-ID: <1430326314.22966.20.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Wed, 29 Apr 2015 12:51:54 -0400
In-Reply-To: <20150429162839.GI6026@localhost>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
