All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "chucklever@gmail.com" <chucklever@gmail.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"SteveD@redhat.com" <SteveD@redhat.com>
Subject: Re: [RFC PATCH v2 0/7] Add a root_dir option to nfs.conf
Date: Tue, 21 May 2019 19:58:00 +0000	[thread overview]
Message-ID: <501262c68530acbce21f39e0015e76805dedfe48.camel@hammerspace.com> (raw)
In-Reply-To: <1BB55244-E893-47A2-B4CB-36CA991A84B0@gmail.com>

On Tue, 2019-05-21 at 15:06 -0400, Chuck Lever wrote:
> > On May 21, 2019, at 2:17 PM, Trond Myklebust <
> > trondmy@hammerspace.com> wrote:
> > 
> > On Tue, 2019-05-21 at 13:40 -0400, Chuck Lever wrote:
> > > Hi Trond -
> > > 
> > > > On May 21, 2019, at 8:46 AM, Trond Myklebust <trondmy@gmail.com
> > > > >
> > > > wrote:
> > > > 
> > > > The following patchset adds support for the 'root_dir'
> > > > configuration
> > > > option for nfsd in nfs.conf. If a user sets this option to a
> > > > valid
> > > > directory path, then nfsd will act as if it is confined to a
> > > > chroot
> > > > jail based on that directory. All paths in /etc/exporfs and
> > > > from
> > > > exportfs are then resolved relative to that directory.
> > > 
> > > What about files under /proc that mountd might access? I assume
> > > these
> > > pathnames are not affected.
> > > 
> > That's why we have 2 threads. One thread is root jailed using
> > chroot,
> > and is used to talk to knfsd. The other thread is not root jailed
> > (or
> > at least not by root_dir) and so has full access to /etc, /proc,
> > /var,
> > ...
> > 
> > > Aren't there also one or two other files that maintain export
> > > state
> > > like /var/lib/nfs/rmtab? Are those affected?
> > 
> > See above. They are not affected.
> > 
> > > IMHO it could be less confusing to administrators to make
> > > root_dir an
> > > [exportfs] option instead of a [mountd] option, if this is not a
> > > true
> > > chroot of mountd.
> > 
> > It is neither. I made in a [nfsd] option, since it governs the way
> > that
> > both exportfs and mountd talk to nfsd.
> 
> My point is not about implementation, it's about how this
> functionality
> is presented to administrators.
> 
> In nfs.conf, [nfsd] looks like it controls what options are passed
> via
> rpc.nfsd. That still seems like a confusing admin interface.
> 
> IMO admins won't care about who is talking to whom. They will care
> about
> how the export pathnames are interpreted. That seems like it belongs
> squarely with the exportfs interface.
> 

With the exportfs interface, yes. However it is not specific to the
exportfs utility, so to me [exportfs] is more confusing than what
exists now.

OK, so what if we put it in [general] instead, and perhaps rename it
"export_rootdir"?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com



  reply	other threads:[~2019-05-21 19:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 12:46 [RFC PATCH v2 0/7] Add a root_dir option to nfs.conf Trond Myklebust
2019-05-21 12:46 ` [RFC PATCH v2 1/7] mountd: Ensure we don't share cache file descriptors among processes Trond Myklebust
2019-05-21 12:46   ` [RFC PATCH v2 2/7] Add a simple workqueue mechanism Trond Myklebust
2019-05-21 12:46     ` [RFC PATCH v2 3/7] Add utilities for resolving nfsd paths and stat()ing them Trond Myklebust
2019-05-21 12:46       ` [RFC PATCH v2 4/7] Add a helper to return the real path given an export entry Trond Myklebust
2019-05-21 12:46         ` [RFC PATCH v2 5/7] Add helpers to read/write to a file through the chrooted thread Trond Myklebust
2019-05-21 12:47           ` [RFC PATCH v2 6/7] Add support for the nfsd rootdir configuration option to rpc.mountd Trond Myklebust
2019-05-21 12:47             ` [RFC PATCH v2 7/7] Add support for the nfsd root directory to exportfs Trond Myklebust
2019-05-21 17:40 ` [RFC PATCH v2 0/7] Add a root_dir option to nfs.conf Chuck Lever
2019-05-21 18:17   ` Trond Myklebust
2019-05-21 18:59     ` Trond Myklebust
2019-05-21 19:06     ` Chuck Lever
2019-05-21 19:58       ` Trond Myklebust [this message]
2019-05-28 15:25         ` Steve Dickson
2019-05-28 16:44           ` Trond Myklebust
2019-05-28 16:47             ` Chuck Lever
2019-05-28 16:50               ` Trond Myklebust
2019-05-28 17:40             ` Steve Dickson
2019-05-28 18:19               ` Trond Myklebust
2019-05-28 19:33                 ` Steve Dickson
2019-05-28 15:30         ` Chuck Lever

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=501262c68530acbce21f39e0015e76805dedfe48.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=SteveD@redhat.com \
    --cc=chucklever@gmail.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.