mountd v4root ignores anonuid and anongid for pseudo file system

mountd v4root ignores anonuid and anongid for pseudo file system

[Leonhard Preis]

[-- Attachment #1.1: Type: text/plain, Size: 4616 bytes --]

Hi!

Recently I have been investigating[1] why Vagrant’s automatically
created NFS shares fail to mount when using NFSv4 on Ubuntu 16.04 while
they work fine on Debian Stretch. In the end the cause really is
trivial: Debian created my home directory with 0755 while Ubuntu went
with 0700. The pseudo file system created by mountd seems to mirror
these permissions while ignoring that Vagrant set
`all_squash,anonuid=1000,anongid=1000`. Thus the client trying to mount
the exported directory is denied access. In my opinion this is a bug
since uid and gid 1000 would have access to the home directory. But I do
see that a second NFS share without the exact same options would create
a dilemma. At the very least a log message indicating this situation
would be very helpful. Nevertheless I’m not too familiar with NFS and
would appreciate your take on this.

While the solution is simple my lack of knowledge had me dive deep into
the web to understand what was going wrong. My biggest obstacle was
definitely the documentation. While the automatically created pseudo
file system was introduced back in 2010[8][9] it is hardly documented[5]
. The closest one can get to understand to what’s happening without
diving into the source code and the accompanying git log itself is a
very outdated discussion from before it was implemented and a note
saying that “all of this has since been mostly fixed”[6]. Meanwhile
almost every tutorial on NFSv4 I remember reading last week still claims
you need to set up a pseudo root. While some may not claim it there is
not a single one explaining what is happening if you don’t including the
man page[3][4][12]:

> For NFSv4, there is a distinguished filesystem which is the root of
all exported filesystem.  This is specified with fsid=root or fsid=0
both of which mean exactly the same thing.

Especially confusing is the following statement from mountd’s man page[4]:

> The rpc.mountd daemon implements the server side of the NFS MOUNT
protocol, an NFS side protocol used by NFS version 2 [RFC1094] and NFS
version 3 [RFC1813].

For me this sounds almost like NFSv4 does not use mountd. Apparently
even Novell thinks that[11]:

> rpc.mountd — […] This is not used with NFSv4.

Last but not least it’s not exactly helping that mountd does not log its
debug stuff to journald, only daemon.log (Debian) or syslog (Ubuntu). I
admit to failing to find these logs until the end when I grep’d for
“v4root” in the log directories. But I have seen that there’s something
happening in regards to systemd with version 2 of nfs-utils so that
point may be moot.

Oh, and one more thing: mountd hiding the pseudo exports to showmount[2]
and exportfs without an option to show them anyway is yet another hint
denied. My personal highlight is the, usually top-notch, Arch Wiki[7]
which has a (disputed) claim[7] that NFS requires shares to reside below
/srv. I hope to find some time this week to improve their documentation.

While I may have had a lot of fun with the documentation, I have no
complaints about the rock-solid software itself and want to use this
opportunity to thank the developers for all their efforts!

As I wrote before I kindly ask for your opinion on the matter and what I
may have missed. Thank you!

Cheers,

Leonhard

[1] https://github.com/mitchellh/vagrant/issues/8279

[2]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=de108c531e29ba936a68a6efb99095ad6d6cec8f

[3]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/exportfs/exports.man;h=d8de6bec2583144bace5a7352d5db58e0882e60d;hb=HEAD


[4]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/mountd/mountd.man;h=9978afcdb4ccb3ef59e5007fa93a1519062cb45c;hb=HEAD

[5] http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

[6] http://wiki.linux-nfs.org/wiki/index.php/Pseudofilesystem_improvements

[7]
https://wiki.archlinux.org/index.php/NFS/Troubleshooting#mount.nfs4:_access_denied_by_server_while_mounting

[8]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=b25694320f2bdd79de82f2003209b8229eafff36

[9]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=3b777b084a438f55482c8bf7508903ff4c30e1db

[10]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=de108c531e29ba936a68a6efb99095ad6d6cec8f

[11] https://www.novell.com/coolsolutions/feature/17581.html

[12]
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/exportfs/exportfs.man;h=91d3589e38d62cb72a343b13b10f0052aec1cbfd;hb=HEAD



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: mountd v4root ignores anonuid and anongid for pseudo file system

[J. Bruce Fields]

On Mon, Mar 20, 2017 at 01:17:40PM +0100, Leonhard Preis wrote:
> Recently I have been investigating[1] why Vagrant’s automatically
> created NFS shares fail to mount when using NFSv4 on Ubuntu 16.04 while
> they work fine on Debian Stretch. In the end the cause really is
> trivial: Debian created my home directory with 0755 while Ubuntu went
> with 0700. The pseudo file system created by mountd seems to mirror
> these permissions while ignoring that Vagrant set
> `all_squash,anonuid=1000,anongid=1000`. Thus the client trying to mount
> the exported directory is denied access. In my opinion this is a bug
> since uid and gid 1000 would have access to the home directory. But I do
> see that a second NFS share without the exact same options would create
> a dilemma. At the very least a log message indicating this situation
> would be very helpful. Nevertheless I’m not too familiar with NFS and
> would appreciate your take on this.

Access denied due to inadequate permissions is much too common for us to
log by default.

> While the solution is simple my lack of knowledge had me dive deep into
> the web to understand what was going wrong. My biggest obstacle was
> definitely the documentation. While the automatically created pseudo
> file system was introduced back in 2010[8][9] it is hardly documented[5]
> . The closest one can get to understand to what’s happening without
> diving into the source code and the accompanying git log itself is a
> very outdated discussion from before it was implemented and a note
> saying that “all of this has since been mostly fixed”[6]. Meanwhile
> almost every tutorial on NFSv4 I remember reading last week still claims
> you need to set up a pseudo root. While some may not claim it there is
> not a single one explaining what is happening if you don’t including the
> man page[3][4][12]:

Patches definitely welcome, this is a common source of confusion.

> Especially confusing is the following statement from mountd’s man page[4]:
> 
> > The rpc.mountd daemon implements the server side of the NFS MOUNT
> protocol, an NFS side protocol used by NFS version 2 [RFC1094] and NFS
> version 3 [RFC1813].

Yes, an extra sentence or two would be useful.  I'm not sure exactly
what, maybe something like:

	It is also responsible for helping the kernel map path names and
	filehandles to exports, for all NFS versions.

> For me this sounds almost like NFSv4 does not use mountd. Apparently
> even Novell thinks that[11]:
> 
> > rpc.mountd — […] This is not used with NFSv4.
> 
> Last but not least it’s not exactly helping that mountd does not log its
> debug stuff to journald, only daemon.log (Debian) or syslog (Ubuntu). I
> admit to failing to find these logs until the end when I grep’d for
> “v4root” in the log directories. But I have seen that there’s something
> happening in regards to systemd with version 2 of nfs-utils so that
> point may be moot.

Huh.  I was watching logs with "journalctl -f" just yesterday and seeing
some mountd messages.  I'm not sure what's up there.

> Oh, and one more thing: mountd hiding the pseudo exports to showmount[2]
> and exportfs without an option to show them anyway is yet another hint
> denied.

We wouldn't want them visible over the MOUNT protocol (what showmount
uses), but I agree that an exportfs option might be useful.  For
debugging purposes it can also be useful to cat
/proc/net/rpc/nfsd.{export,fh}/content, which might be worth
documenting.

--b.

> My personal highlight is the, usually top-notch, Arch Wiki[7]
> which has a (disputed) claim[7] that NFS requires shares to reside below
> /srv. I hope to find some time this week to improve their documentation.
> 
> While I may have had a lot of fun with the documentation, I have no
> complaints about the rock-solid software itself and want to use this
> opportunity to thank the developers for all their efforts!
> 
> As I wrote before I kindly ask for your opinion on the matter and what I
> may have missed. Thank you!
> 
> Cheers,
> 
> Leonhard
> 
> [1] https://github.com/mitchellh/vagrant/issues/8279
> 
> [2]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=de108c531e29ba936a68a6efb99095ad6d6cec8f
> 
> [3]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/exportfs/exports.man;h=d8de6bec2583144bace5a7352d5db58e0882e60d;hb=HEAD
> 
> 
> [4]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/mountd/mountd.man;h=9978afcdb4ccb3ef59e5007fa93a1519062cb45c;hb=HEAD
> 
> [5] http://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration
> 
> [6] http://wiki.linux-nfs.org/wiki/index.php/Pseudofilesystem_improvements
> 
> [7]
> https://wiki.archlinux.org/index.php/NFS/Troubleshooting#mount.nfs4:_access_denied_by_server_while_mounting
> 
> [8]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=b25694320f2bdd79de82f2003209b8229eafff36
> 
> [9]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=3b777b084a438f55482c8bf7508903ff4c30e1db
> 
> [10]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=patch;h=de108c531e29ba936a68a6efb99095ad6d6cec8f
> 
> [11] https://www.novell.com/coolsolutions/feature/17581.html
> 
> [12]
> http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=blob;f=utils/exportfs/exportfs.man;h=91d3589e38d62cb72a343b13b10f0052aec1cbfd;hb=HEAD
> 
>