Greetings list, I have been scouring the Web (and nfs-utils, kernel, and libmount source trees) for several days now to try to understand what happens during the mount procedure when the (NFSv4) share is authenticated by GSS (or rather, Kerberos). What I am trying to do is mount an NFS share as myself (a regular user) with my own Kerberos credentials. What I am seeing is an insistence on the part of some part of the system to populate the $RPC_PIPEFS/nfs/$CLIENT/krb5 pseudo-file with “mech=krb5 uid=0 service=* enctypes=…”, which then gets ferried on to rpc.gssd, which dutifully goes looking for machine credentials that do not exist. Instead (at least by my reading of the source code for what kind of outcome I want), that pseudo-file should say “mech=krb5 uid=1000 enctypes=…” (ie no service=…) etc. If it said that then rpc.gssd would (likely) do the right thing. My question then: what is populating that pseudo-file in the rpc_pipefs filesystem? (and when is it doing it?) How come it insists on directing rpc.gssd to look for machine credentials for root instead of the uid of the caller (me)? I have been unable to locate any information on the role of rpc_pipefs beyond a blurb in the kernel source code, nor have I been able to locate anything that looks remotely like a protocol diagram for the NFSv4(+gss/krb5) mounting process, so I guess my question reduces to: where do I go looking for a solution to this problem? (Note this is all recent Ubuntu, 20.04 and newer, and I already have Mac clients connecting to the server. More context and details here: https://askubuntu.com/questions/1382702/21-10-client-gssd-cant-seem-to-see-user-credentials-cache-when-mounting-nfsv4) Thanks in advance for any insight, -- Dorian Taylor Make things. Make sense. https://doriantaylor.com
Attachment:
signature.asc
Description: Message signed with OpenPGP
