On Tue, 2019-05-21 at 18:17 +0000, Trond Myklebust 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, > ... I should perhaps note that the reason why I used a second thread, rather than using fork()ed processes like the rest of the mountd code is to allow the sharing of file descriptors, so that the unconfined thread can open files that can then be easily used by the root jailed thread. This means that if you have an old glibc that does not support POSIX threads, then the 'root_dir' functionality is disabled. Ditto if you have a kernel that does not support the unshare() system call or if it does not support openat()+fstatat(). > > 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. > -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
