linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "bfields@fieldses.org" <bfields@fieldses.org>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"steved@redhat.com" <steved@redhat.com>
Subject: Re: [RFC PATCH 0/5] Add a chroot option to nfs.conf
Date: Wed, 15 May 2019 14:38:50 +0000	[thread overview]
Message-ID: <fc8f468f9f9086d8be51d570916fda330a42bbee.camel@hammerspace.com> (raw)
In-Reply-To: <20190515140112.GA9291@fieldses.org>

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
trond.myklebust@hammerspace.com



      reply	other threads:[~2019-05-15 14:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 20:41 [RFC PATCH 0/5] Add a chroot option to nfs.conf 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 J. Bruce Fields
2019-05-15 14:01 ` [RFC PATCH 0/5] Add a chroot option to nfs.conf J. Bruce Fields
2019-05-15 14:38   ` Trond Myklebust [this message]

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=fc8f468f9f9086d8be51d570916fda330a42bbee.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=steved@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).