Linux-NFS Archive on
 help / color / Atom feed
From: Trond Myklebust <>
To: "" <>
Cc: "" <>,
	"" <>
Subject: Re: [RFC PATCH 0/5] Add a chroot option to nfs.conf
Date: Wed, 15 May 2019 14:38:50 +0000
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 2019-05-15 at 10:01 -0400, J. Bruce Fields wrote:
> On Tue, May 14, 2019 at 04:41:48PM -0400, Trond Myklebust wrote:
> > The following patchset aims to allow the configuration of a 'chroot
> > jail' to rpc.nfsd, and allowing us to export a filesystem /foo (and
> > possibly subtrees) as '/'.
> This is great, thanks!  Years ago I did an incomplete version that
> worked by just string manipulations on paths.  Running part of mountd
> in
> a chrooted thread is a neat way to do it.
> If I understand right, the only part that's being run in a chroot is
> the
> writes to /proc/net/sunrpc/*/channel files.  So that means that the
> path
> included in writes to /proc/net/sunrpc/nfsd_fh/channel will be
> resolved
> with respect to the chroot by the kernel code handling the write.
> That's not the only place in mountd that uses export paths, though.
> What about:
> 	- next_mnt(), which compares paths from the export file to
> paths
> 	  in /etc/mtab.
> 	- is_mountpoint, which stats export paths.
> 	- match_fsid, which stats export paths.
> Etc.  Doesn't that stuff also need to be done with respect to the
> chroot?  Am I missing something?

Good feedback. Thanks!

Yes, I do need to fix up those comparisons too. I suspect that we want
to do the stat() in the chrooted namespace so that we resolve symlinks
etc correctly. That should be easy to add: the workqueue implementation
is generic, so adding a new operation is pretty trivial.

For the path comparisons in next_mnt(), things are a little murkier.
I'm not overly happy with a solution where user space tries to resolve
paths because the presence of symlinks, bind mounts, etc can and do
mean that user space will get that wrong. Perhaps the right solution is
to do an open() and check that it ends up in the right place (i.e.
check the fsid/inode number with a fstat())?

Trond Myklebust
Linux NFS client maintainer, Hammerspace

      reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 20:41 Trond Myklebust
2019-05-14 20:41 ` [RFC PATCH 1/5] mountd: Ensure we don't share cache file descriptors among processes Trond Myklebust
2019-05-14 20:41   ` [RFC PATCH 2/5] Add a simple workqueue mechanism Trond Myklebust
2019-05-14 20:41     ` [RFC PATCH 3/5] Add a helper to write to a file through the chrooted thread Trond Myklebust
2019-05-14 20:41       ` [RFC PATCH 4/5] Add support for chrooted exports Trond Myklebust
2019-05-14 20:41         ` [RFC PATCH 5/5] Add support for chroot in exportfs Trond Myklebust
2019-05-15 14:14         ` [RFC PATCH 4/5] Add support for chrooted exports bfields
2019-05-15 14:01 ` [RFC PATCH 0/5] Add a chroot option to nfs.conf bfields
2019-05-15 14:38   ` Trond Myklebust [this message]

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-NFS Archive on

Archives are clonable:
	git clone --mirror linux-nfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-nfs linux-nfs/ \
	public-inbox-index linux-nfs

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox