get_cred starting realm

[Greg Hudson]

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.

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

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

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

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.

> It's no more magic that any of the other ccconfigs we store now, nor
> time offset, and so on.

It is definitely more magic than other cache configs, which all come
from higher layers.  Regardless, I would describe the implementation of
cache configs as magic.  Cache types can only distinguish between normal
creds and config entries by scraping.  Config entries appear when
iterating over credentials--which of course has useful consequences for
callers who copy caches, and negative consequence sfor callers like
klist who display them.

The way time offsets are handled is seriously magic, with a ton of
unfortunate edge cases for cache collections.