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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx >>>>>>>>> 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.
