interaction between caches, KEYRING, and NFS

[Simo Sorce]

On Tue, 2017-03-14 at 18:59 +0000, Charles Hedrick wrote:
> The KEYRING mechanism is nice, in many ways. But it has some
> unexpected effects.
> 
> There’s a “primary” key for the usual keyring. But this is a global
> object. That is, which cache is primary is the same for all sessions,
> and for NFS.
> 
> Imagine I’m a privileged user. I start out logged in as hedrick at CS.RU
> TGERS.EDU<mailto:hedrick at CS.RUTGERS.EDU>. I now decide to do some
> administrative work. I kinit as admin at CS.RUTGERS.EDU<mailto:hedrick.a
> dmin at CS.RUTGERS.EDU>. What happens depends upon exactly how
> KRB5CCNAME is set.
> 
> Depending upon how I logged in, KRB5CCNAME may be set either to
> KEYRING:persistent:NNN or KEYRING:persistent:NNN:XXX.
> 
> If it’s set to KEYRING:persistent:NNN:XXX, kinit will fail with an
> error "kinit: Can't create new subsidiary cache because default cache
> is already a subsidiary while generating new ccache.” Also, “klist
> -l” will fail. Actually, it will appear to work, but only show me the
> one cache even if there are others.
> 
> If KRB5CCNAME is set to KEYRING:persistent:NNN, kinit will work. It
> will create a new cache for the new credentials, and make it primary.
> The problem with making it primary is that if NFS happens to check my
> credentials at that point it will fail. rpc.gssd uses a GSSAPI
> interface that only checks the primary credentials. Of course admin
> won’t mean anything to NFS, since my file access will all need to be
> done as hedrick.
> 
> About the best I could come up with is to wrap kinit with a script
> that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit, so
> it always works. It then does kswitch to switch back to my primary
> cache, so that NFS doesn’t break. Finally, it checks whether with my
> original setting of KRB5CCNAME I’ll see the cache I just set up.
> There’s a good chance I won’t. In that case it prints a command to
> set KRB5CCNAME appropriately, which I can cut and paste.
> 
> I also have a skshow, which helps me switch between caches if I don’t
> need to reauthentication. “skshow principal” looks for a cache for
> that principal and prints a command line to set KRB5CCNAME
> appropriately.
> 
> If anyone has better ideas I’d love to hear them.
> 
> (I note that using FILE rather than KEYRING doesn’t produce results
> that are as surprising, but I’d still want wrapper scripts to help
> maintain multiple caches.)

Set KRB5CNAME to a FILE ccache for administrative work so that it is
completely disjoint from your user ccaches and NFS will not have to
deal with it. Or make sure to walk into the NFS mount points with your
user before doing admin work.

Simo.