[19154] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: get_cred starting realm

daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Wed Apr 29 13:01:58 2015

Date: Wed, 29 Apr 2015 13:01:45 -0400 (EDT)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20150429162839.GI6026@localhost>
Message-ID: <alpine.GSO.1.10.1504291259370.22210@multics.mit.edu>
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, 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
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post