[37906] in Kerberos
Re: interaction between caches, KEYRING, and NFS
daemon@ATHENA.MIT.EDU (Charles Hedrick)
Thu Mar 16 12:43:22 2017
From: Charles Hedrick <hedrick@rutgers.edu>
To: Jason L Tibbitts III <tibbs@math.uh.edu>
Date: Thu, 16 Mar 2017 16:43:00 +0000
Message-ID: <B1A515D0-755A-4F71-9CA8-3CA6749083E1@rutgers.edu>
In-Reply-To: <ufalgs5nq6u.fsf@epithumia.math.uh.edu>
Content-Language: en-US
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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@math.uh.edu<mailto:tibbs@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
