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

[Greg Hudson via RT]

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

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

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’t 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.