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

[Charles Hedrick via RT]

roc.gssd seems to interact better with /tmp. It looks for all files owned by the user, verifies that they have principals and credentials, and then picks the newest. It could certainly do the same thing with the KEYRING collection. I’m thinking that at the moment I probably want to use /tmp, either in place of KEYRING or possibly just as a place to make sure there’s at  least one current credential file for each active user.

The issue isn’t just cron jobs. Depending upon how you login (whether login on kerberized ssh) you can end up with your KRB5CCNAME set simply to KEYRING:persisent:UID. In effect that gives you the current primary cache for the collection. It’s quite possible that two sessions could have the same setting. (Indeed that seems to be the default when using sssd and sshd with default settings.) That means that if one session does a kdestroy (or if sshd_config is set to destroy the credentials), that can cause the other session to lose its credentials as well. It doesn’t help that there’s no way to configure krb5.conf with the random 6 digits at the end of the template (at  least I couldn’t find it documented) and sshd doesn’t seem to have that functionality. So interaction between different ssh sessions seems quite likely.

These’s no magic solution to this. I’m probably going to disable the automatic destroy on logout in sshd_config, and take the view that if a user does kdestroy they deserve what they get. To avoid leaving credentials lying around too long, rather than having users do kdestroy on login, I’m going to default to a fairly short credential lifetime, with a daemon that automatically renews if there’s any process still active for the user. 

Cron is actually the least serious issue, since the cron job can easily use a separate credential file that won’t interfere with interactive use.

I think this is going to require a combination of getting users to follow specific practices, a daemon, and careful choice of parameters. But the combination of KEYRING design, sshd design, and rpc.gssd design don’t seem to fit well together.

> On Mar 3, 2017, at 5:18:55 PM, Greg Hudson via RT <rt-comment at krbdev.mit.edu> wrote:
> 
> 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.