Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: [RFC PATCH v2 0/7] Add a root_dir option to nfs.conf
From:   Chuck Lever <chucklever@gmail.com>
In-Reply-To: <25ce1d3aa852ecd09ff300233aea60b71e6e69df.camel@hammerspace.com>
Date:   Tue, 21 May 2019 15:06:08 -0400
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Steve Dickson <SteveD@redhat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BB55244-E893-47A2-B4CB-36CA991A84B0@gmail.com>
References: <20190521124701.61849-1-trond.myklebust@hammerspace.com>
 <708D03B6-AEE1-42D6-ABDF-FB1AA5FC9A94@gmail.com>
 <25ce1d3aa852ecd09ff300233aea60b71e6e69df.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On May 21, 2019, at 2:17 PM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>=20
> On Tue, 2019-05-21 at 13:40 -0400, Chuck Lever wrote:
>> Hi Trond -
>>=20
>>> On May 21, 2019, at 8:46 AM, Trond Myklebust <trondmy@gmail.com>
>>> wrote:
>>>=20
>>> 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.
>>=20
>> What about files under /proc that mountd might access? I assume these
>> pathnames are not affected.
>>=20
> 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,
> ...
>=20
>> Aren't there also one or two other files that maintain export state
>> like /var/lib/nfs/rmtab? Are those affected?
>=20
> See above. They are not affected.
>=20
>> 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.
>=20
> 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.


--
Chuck Lever
chucklever@gmail.com