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

[Charles Hedrick via RT]

I’ve redesigned my strategy to take all of this into account.

rpc.gssd use the primary cache from KEYRING:persistent:NNN, and all caches in /tmp owned by the user.

As you point out, Redhat by default shares the primary cache in KEYRING for all sessions.

I have modified renewd to renew just the primary cache in KEYRING, and any caches matching /tmp/krb5cc_NNN or /tmp/krb5cc_NNN_foo that are owned by the user.

To avoid race conditions, before renewing the first cache, it copies renewed credentials to /tmp/krb5cc_NNN-renew, which will also be seen by rpc.gssd. That way if rpc.gssd happens to look at a cache while it’s in an invalid state during renewal, the temporary cache will still let it proceed. 

I think this will support the common cases. It’s the best I can think to do. My primary goal is to make NFS just work for users who just login in default ways. Even for cron jobs they’ll probably have to follow instructions, though at the moment I think those instructions will just be to register with credserv for that system, and start their job with kgetcred (which pulls credentials from a server running credserv, thus avoiding the need to have a keytab where root could potentially steal it and use it anywhere).

> On Mar 4, 2017, at 12:41:28 AM, Greg Hudson via RT <rt-comment at krbdev.mit.edu> wrote:
> 
>>   It doesn窶冲 help that there窶冱 no way to
>>   configure krb5.conf with the random 6 digits at the end of the
>>   template (at  least I couldn窶冲 find it documented) and sshd
>>   doesn窶冲 seem to have that functionality.
> 
> sshd could do this (and I think normally does, but it may be 
> configured not to in CentOS), but I don't think that would make sense 
> in krb5.conf.  You don't want a random six digits every time the 
> default ccache is resolved; you would want the same six digits for 
> each login session, or perhaps some other associated group of 
> processes.  We could add a path substitution for the value of 
> getsid(), perhaps, but I'm not sure whether or not that would wind up 
> being useful.
> 
>> I知 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.
> 
> I believe that is Red Hat's general system design for using Kerberos--
> that all login sessions use the same collection and you don't destroy 
> tickets on logout.  It's a little different than the more traditional 
> design of using a separate cache for each login session and destroying 
> tickets at the end of the session.
> 
>> But the combination of KEYRING design, sshd design, and
>> rpc.gssd design don稚 seem to fit well together.
> 
> NFS and Kerberos have always been somewhat at odds because so little 
> process context is communicated from the filesystem-accessing process 
> and rpc.gssd.  AFS has the concept of "process authentication groups" 
> with explicit credential management from userspace, which is sometimes 
> cumbersome but has predictable semantics.  I'm not recommending using 
> AFS over NFS, but it provides one example of how a network filesystem 
> can be integrated with a userspace authentication system.
> 
> Credential cache collections (of which KEYRING is one implementation) 
> are not designed to address the NFS problem.  Typically each cache 
> within a collection has a different client principal.  If all login 
> sessions for a user share the same cache collection, they will also be 
> making use of the same cache for the username at defaultrealm client 
> principal, which means that kdestroy will destroy that one cache 
> containing those credentials.  Any other caches in that collection 
> would be for different client principals and probably would not grant 
> the same access rights to the NFS server.