get_cred starting realm
nico at cryptonector.com
Wed Apr 29 14:05:01 EDT 2015
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
> * 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.
More information about the krbdev