bad principal used by gssd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux