Apologies, I had missed the additional activity on this topic. TL;DR: `mount` of an nfsv4 volume as an unprivileged user works with Kerberos, for some definition of “works”, as long as root also has a copy of the unprivileged user’s TGT. > On Jan 3, 2022, at 4:45 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > As noted, the main issue is the bind() privileges needed for AUTH_SYS. > > When using AUTH_GSS, the knfsd server doesn't care about the > originating port, which would allow unprivileged mounts to go ahead > provided that the user specifies the 'noresvport' mount option on the > client. Isn't that working? Indeed, mounting an nfs volume as an unprivileged user seems to work in principle; it looks like what’s happening is the mounting process fails to transmit (or fails to make use of a successful transmission of) the correct uid at some point along the line. consider the relevant part of the server’s /etc/exports: /srv/home/dorian *(rw,nohide,insecure,no_subtree_check,async,pnfs,sec=krb5p:krb5i:krb5:sys) and the client’s /etc/fstab: deuce:/home/dorian /net/dorian nfs4 sec=krb5p,soft,noresvport,noauto,user 0 0 Then the procedure: * start rpc.gssd with -n to prevent it from looking for service principals * `kinit` as myself, also `sudo kinit dorian` to get a ticket for me owned by root * then just execute `mount deuce:/home/dorian` as myself. Both my user and root have to have a TGT for dorian@REALM or it won’t work. Same with rpc.gssd suppressing service principals, but I suspect that is just incidental. It’s also worth noting that the connection appears to be unconditionally made on a privileged port even though `insecure` was set on the server and `noresvport` was specified on the client. I am afraid I do not have any additional visibility into the mounting procedure save to note that that `krb5` pipefs pseudo-file looks like it’s getting its information from rpc.idmapd, which in turn is getting its own information from Kerberos principals. I don’t know how that pipefs mechanism works though. If I were to hazard a guess as to what was happening, it’s that mount.nfs(8) internals are losing track of the caller’s real uid when escalating privileges to do the mount. That is consistent with a) root also needing an unprivileged TGT and b) the client unconditionally connecting on port <1024. -- Dorian Taylor Make things. Make sense. https://doriantaylor.com
Attachment:
signature.asc
Description: Message signed with OpenPGP
