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 <ti...@math.uh.edu<mailto:ti...@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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
