All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonhard Preis <leonhard.preis@radarservices.com>
To: <linux-nfs@vger.kernel.org>
Subject: mountd v4root ignores anonuid and anongid for pseudo file system
Date: Mon, 20 Mar 2017 13:17:40 +0100	[thread overview]
Message-ID: <4218b9fa-e215-370a-f913-348e055d33e2@radarservices.com> (raw)


[-- 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 --]

             reply	other threads:[~2017-03-20 12:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20 12:17 Leonhard Preis [this message]
2017-04-13 18:28 ` mountd v4root ignores anonuid and anongid for pseudo file system J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4218b9fa-e215-370a-f913-348e055d33e2@radarservices.com \
    --to=leonhard.preis@radarservices.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.