interaction between caches, KEYRING, and NFS

[Charles Hedrick]

Actually, if I have KRB5CCNAME set to a file in /tmp, and kinit as someone else, e.g. admin, that will reinitialize the file in /tmp, losing my original credentials.

With KEYRING (I’m using Centos 7), because it’s a collection, there’s some hope of maintaining multiple caches properly. If KRB5CCNAME is set to the collection, kinit is smart enough to create a new credentials cache. With FILE:, I’d need to reset KRB5CCNAME or using an explicit -c option to kinit. The problem is that kinit makes the new cache primary. Without NFS that makes sense. With NFS, it can cause trouble.

I see two reasonable solutions:

 * Have rpc.gssd look at the whole KEYRING collection and not just the primary. I don’t think that’s a hard patch, though having GSSAPI on top of Kerberos makes everything more difficult to figure out.
* Have the primary member of the collection be session-specific. But you’d probably need to combine that with the first.

I’m thinking of generating a bug report for rpc.gssd.

On Mar 16, 2017, at 12:26 PM, Jason L Tibbitts III <tibbs at math.uh.edu<mailto:tibbs at math.uh.edu>> wrote:

CH> About the best I could come up with is to wrap kinit with a script
CH> that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit,
CH> so it always works.

I would suggest just using FILE: so there's no chance of the admin
CCACHE messing with your user credentials.