Re: bad principal used by gssd

[bfields@fieldses.org (J. Bruce Fields)]

On Fri, Feb 22, 2019 at 06:36:54PM +0000, Charles Hedrick wrote:
> Would someone please look at
> https://bugzilla.linux-nfs.org/show_bug.cgi?id=318?
> 
> If I’m logged in as hedrick but current credentials are hedrick.admin,
> I have a key ring with credentials for both hedrick and hedrick.admin.
> 
> If gssd needs to recreate its context (e.g. because the credentials
> have expired) it acquires GSSAPI credentials with NONAME. That will
> give it the current selected principal, which is hedrick.admin. Of
> course for NFS only a principal that matches the current UID can work.
> So later in the code it checks to see if the credentials it has are
> for hedrick, and fails. This is kind of silly. If you tell acquire
> what credentials you want, it will look through the keyring and pick
> the right one. So the call to acquire should specify the desired
> principal.
> 
> The bug report gives code to fix it. Because I don’t want to build my
> own gssd, my patch uses LD_PRELOAD to intercept calls, but the code
> could be put into the source in the obvious way.

No comment on whether that's the right behavior (I just don't know), but
for what it's worth I think you'll get a quicker response if it were
possible to just make it a patch against nfs-utils, and post it to the
list instead of that bugzilla.

--b.