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;
Subject: Re: [RFC PATCH v2 0/7] Add a root_dir option to nfs.conf
To:     Trond Myklebust <trondmy@hammerspace.com>,
        "chucklever@gmail.com" <chucklever@gmail.com>
Cc:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
References: <20190521124701.61849-1-trond.myklebust@hammerspace.com>
 <708D03B6-AEE1-42D6-ABDF-FB1AA5FC9A94@gmail.com>
 <25ce1d3aa852ecd09ff300233aea60b71e6e69df.camel@hammerspace.com>
 <1BB55244-E893-47A2-B4CB-36CA991A84B0@gmail.com>
 <501262c68530acbce21f39e0015e76805dedfe48.camel@hammerspace.com>
 <3503ff03-2895-ae1f-7fed-f30d08b0abfb@RedHat.com>
 <c7a5f97693c56ee0a7dd5a9c0848ee97ab3d2a9e.camel@hammerspace.com>
 <0b65f710-f06a-cfd3-a30e-577db8267d5b@RedHat.com>
 <af4e638f44baa4344c5a3b826cc1cbd28253bf1e.camel@hammerspace.com>
From:   Steve Dickson <SteveD@RedHat.com>
Message-ID: <46dbdb00-ff89-cd6e-24c7-f66ca81cb0c9@RedHat.com>
Date:   Tue, 28 May 2019 15:33:57 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <af4e638f44baa4344c5a3b826cc1cbd28253bf1e.camel@hammerspace.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


On 5/28/19 2:19 PM, Trond Myklebust wrote:
> On Tue, 2019-05-28 at 13:40 -0400, Steve Dickson wrote:
>>
>> On 5/28/19 12:44 PM, Trond Myklebust 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.
>> By granularity I meant have different roots for different exports.
>> Meaning /mnt/foo/exports/foo and /mnt/bar/exports/bar
>> would still appear as /foo and /bar
> 
> No. That should be done using bind mounts. Otherwise we end up with
> /etc/nfs.conf and /etc/exports depending on being mutually consistent.
> That would be awkward.
Fine... 

> 
>> As you explain later in this thread, there is going to be a nfs.conf
>> and exports for each container so maybe this is not necessary?? 
>>
>> Maybe I'm misunderstanding how this feature should/will be used.
> 
> As I've already said, it can be used to do what you are proposing, but
> only in conjunction with bind mounts.
> 
>>
>>> 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.
>>>
>>>> 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.
>>>
>> I think a new exports sections with a rootdir variable makes sense.
>> It is changing the root of the exports... 
>>
>> But I could also live with a export_rootdir in the general section.
>>
>> Question:
>> How is this different than pseudo root? 
>>
>> Isn't this basically a way to set the pseudo for v3? 
> 
> Sort of, yes.
> 
>> What is going to override whom? Meaning if both 
>> fsid=/mnt/foo and rootdir=/mnt/bar which one will be used?
>>
>>
> Both. However the entry in /etc/exports will be relative to /mnt/bar.
> In other words, the NFSv4 root would be fsid=/mnt/foo, which translates
> as /mnt/bar/mnt/foo in the 'init' namespace.
> 
Ok... 

So what do you want to do... 

[exports]
 rootdir=/mnt/foo

or 

[general]
   export_rootdir=/mnt/bar

steved.