Re: [RFC PATCH v2 0/7] Add a root_dir option to nfs.conf

[Chuck Lever <chucklever@gmail.com>]

> On May 28, 2019, at 12:44 PM, Trond Myklebust <trondmy@hammerspace.com> wrote:
> 
> On Tue, 2019-05-28 at 11:25 -0400, Steve Dickson wrote:
>> 
>> On 5/21/19 3:58 PM, Trond Myklebust wrote:
>>> 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"?
>>> 
>> I'm just catching up... my apologies tartness...
>> 
>> So setting root_dir effects *all* exports in /etc/exports? 
>> If that is the case, that one variable can change hundreds
>> of export... is that what we really want?
>> 
>> Wouldn't be better to have a little more granularity? 
> 
> Can you explain what you mean? The intention here is that if you have
> all your exported filesystems set up in a subtree under
> /mnt/my/exports, then you can remove that unnecessary prefix.
> 
> So, for instance, if I'm trying to export /mnt/my/exports/foo and
> /mnt/my/exports/bar, then I can make those two filesystems appear as
> /foo, and /bar to the remote clients.
> 
> If an admin wants to rearrange all the paths in /etc/exports, and make
> a custom namespace, then that is possible using bind mounts: just
> create a directory /my_exports, and use mount --bind to attach the
> necessary mountpoints into the right spots in /my_exports, then use
> export_rootdir to remove the /my_exports prefix.

Just to be clear, do you expect that each mount namespace on a
Linux NFS server would have its own /etc/exports and /etc/nfs.conf ?

Maybe you stated that before, and I missed it.


>> As for where root_dir should go, I think it makes senses
>> to create a new [exportfs] section and have mountd read it
>> from there. I think that would be more straightforward if
>> we continue with the big hammer approach where any and all
>> exports are effected. 
>> 
> 
> Fair enough, I can add the [exports] section if you all agree that is
> an appropriate place.
> 
> -- 
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> trond.myklebust@hammerspace.com

--
Chuck Lever
chucklever@gmail.com