> On Dec 24, 2021, at 2:15 PM, Dorian Taylor (Lists) <lists@xxxxxxxxxxxxxxxx> wrote: > > >> On Dec 24, 2021, at 12:28 PM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: >> >> man 8 rpc.gssd >> >> The "-n" option might be helpful. > > Interesting, thanks. I tried it, but predictably it complained that my ccache was (correctly) owned by uid 1000, not 0. What I’m wondering about is why the uid in the $RPC_PIPEFS/nfs/$CLIENT/krb5 pseudofile is 0 when it should be 1000. Like I’m trying to determine if I have something misconfigured vs whether something is calling geteuid() when it should be calling getuid() (or whatever). Restating my situation: > > * I run `kinit` as myself and get my TGT > * I run `mount -t nfs4 -o sec=krb5p host:/listed/in/fstab/with/user/flag /desired/target` > * I get EPERM with additional information saying the mount was denied by the server (actually a red herring; wireshark shows nothing coherent makes it to the server so the request is summarily denied) > * rpc.gssd -f -vvv shows that the failure is because it can’t find a keytab for various service principals > * problem is I am expecting it to use *my* *user* principal > * I know the mount should work because my Mac is already doing it; it’s the Linux client that’s failing IIRC Linux requires that a mount operation be done by root. If you run gssd with "-n", become root, then kinit as yourself, I think it should work. There has been some discussion about enabling a non-privileged user to perform a mount... it's a bit tricky because the function of mount is to alter the file namespace, which traditionally requires extra privilege to do. Mac OS has had this functionality for ages to enable basic Finder operation. Linux doesn't have it yet. > I have tracked the failure down as far as the pseudo-file $RPC_PIPEFS/nfs/$CLIENT/krb5 containing incorrect information (namely it says “mech=krb5 uid=0 service=*” where it should be saying “mech=krb5 uid=1000”). If that pseudo-file contained the correct information then by all accounts rpc.gssd should do the right thing. Thing is, I don’t know what (the kernel? something else?) populates that pseudo-file, and I have zero leads as to what creates it short of exhaustively poring over the kernel and nfs-utils (and other?) source code. > > (I should also note that I have the debug output on rpc.idmapd also cranked up, and it does report that it interacts with that rpc_pipefs pseudo-filesystem but *not* that krb5 pseudo-file.) > > (I even ran mount.nfs4 in gdb, but since it’s suid and because of that I have to run gdb as root, I’m necessarily going to miss the exact thing I’m looking for.) > > I have two hypotheses: > > * I have misconfigured something, but if I have, I can’t find the documentation needed to un-misconfigure it, because no documentation I have found so far mentions troubleshooting nfsv4+gss/krb5 with user (not machine) credentials, at least with non-root users (despite appearing to be supported in the source code) > > * something is short-circuiting whatever mechanism is supposed to correctly report my (real) uid to whatever other mechanism makes it show up in that krb5 pseudo-file which subsequently directs rpc.gssd’s behaviour, and there isn’t a test case to catch it. AFAIK you are not doing anything wrong. It just isn't supported on Linux at this time. > Either way, if there is a flow diagram kicking around showing all of the parts and pieces of the nfsv4+krb5 mounting process, I would be eternally grateful to see it. I'm not aware of such a diagram. -- Chuck Lever
