> On Dec 25, 2021, at 5:53 PM, Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > 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 mean, you’re the expert, though it looks a heck of a lot like the functionality is present: mount(8) is setuid (and so is mount.nfs), there is the `user` (and separate `users`) mount option in fstab, and I am pretty sure I have mounted things like optical drives and USB keys from a Linux desktop without e.g. entering a password (though I suppose that could have been the work of FUSE or GVFS or something). > AFAIK you are not doing anything wrong. It just isn't supported on Linux at this time. So, here is something interesting: * I run `rpc.gssd -fn -vvv` * in a root shell, I `kinit` as myself * I `mount remotehome:/in/fstab` * miraculously, that $RPC_PIPEFS/nfs/$CLIENT/krb5 pseudo-file now reports “mech=krb5 uid=1000…” * after some carping about credential caches, rpc.gssd works correctly and the share is mounted as me. I didn’t mount the NFS share though, root did, with my Kerberos TGT. From this I can deduce that that uid=1000 must be coming from rpc.idmapd, because where else could it come from? That’s the only thing that “knows” the relationship between the Kerberos principals and the user IDs on the system. Moreover, what looks like what happened with the credential caches is that even though doing a kinit for my ticket as root, the ccache that rpc.gssd actually *used* to authenticate the share was a different one owned by me (uid 1000) that was also in /tmp at the time. So /tmp/krb5cc_0 is used (presumably by rpc.idmapd) to find out that dorian@REALM -> 1000, but then /tmp/krb5cc_1000_XoaBV1 (by rpc.gssd) to actually authenticate the mount. What this is telling me is that there is no reason in principle why a non-root user shouldn't be able to mount an NFSv4 share authenticated by GSS/Kerberos (as both `mount` and `mount.nfs` are setuid, and the fstab entry has `user` in the options; by all means the code to do the job sure looks like it’s in there), but rather the information about the *initial* mapping from Kerberos principal to system uid is not getting transmitted to rpc.gssd. To recap: * when I run `mount remotehome:/in/fstab` as myself, gssd reports reading uid=0 in that pseudo-file; * when I run `mount remotehome:/in/fstab` as root with my ticket, gssd reports uid=1000. although, actually: * it turns out that the only parts that matter are a) rpc.gssd -n, and b) root having a ccache with my ticket in it, in addition to me having one as well. I also appear not to need to be root to do the actual mount though, as `mount` is suid. (aside: it looks like the `noresvport` mount option is ignored, as port <1024 is used to connect whether the real uid invoking `mount` is root or myself.) This is looking more and more like a bug. I wonder what it would take to get it to work properly? -- Dorian Taylor Make things. Make sense. https://doriantaylor.com
Attachment:
signature.asc
Description: Message signed with OpenPGP
