[krbdev.mit.edu #8556] missing primary cache after kdestroy

[Greg Hudson via RT]

It's intentional that a collection might be non-empty but its primary 
cache pointer might point to an empty or expired cache.  Having the 
primary pointer snap to an arbitrarily chosen cache in the collection 
would be surprising, I think.

I agree that it might be better if gssd could know something about the  
environment of the process invoking the filesystem operation, so that 
cron jobs could use a cache that isn't shared with user login 
sessions.  But I don't see a good way to work around that limitation 
within the krb5 library.  gssd could search the default cache 
collection for a usable cache in preference to searching files in 
/tmp, but that's still not completely satisfying.

I believe that Red Hat is working on implementing a KCM server in sssd 
to replace their use of the kernel keyring cache, but I don't know if 
it will directly solve this issue because it still won't isolate a 
long-running job from a short-term user login session from gssd's 
point of view.