get_cred starting realm

[Nico Williams]

On Wed, Apr 29, 2015 at 01:47:49PM -0400, Greg Hudson wrote:
> On 04/29/2015 12:28 PM, Nico Williams wrote:
> >> 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.
> 
> Here is why I consider it to be magic:
> 
> * The caller asks for one cred to be stored, but the result is that two
> creds are stored, as observed by the cache type and by future iterations.

Eh, this already happens, no?  E.g., with the referral realm business.

> * The generic cache store function used to be just a dispatch; now it
> implements some of the responsibilities of the ccache layer.  The cache
> type cannot distinguish between creds intentionally stored by the caller
> and synthetic config entries generated by the generic cache layer.

True, but if it ever becomes a problem then the SPI can be extended.  I
get that that extends to the KCM/CCAPI protocol, but I doubt this will
ever be necessary.  Why would the ccache need to make that distinction?

Alternatively we could have two ccconfigs for this instead of one, and
then have krb5_cc_get_config() for the start-realm ccconfig try up to
both.

> * If a caller copies a cache by iterating and storing, the cache type
> for the destination might observe a start realm config entry being
> stored twice (perhaps with different values), or perhaps only once,
> depending on the iteration order for the source.

Not if the source implements krb5_cc_remove_cred().

> * The starting-realm entry is only synthesized if you store_cred after
> initializing the same handle.  If you open, initialize, close, open, and
> store, no starting-realm entry is synthesized.

True.  (This too could be handled.  But does this ever happen?)

> These are not necessarily practical issues.  But it's unquestionable
> that any formal description of the new contract for the initialize,
> store, get_config, and iteration functions would be significantly more
> fiddly than the old contract.

I think they are not practical issues.

Nico
--