> On Thu, Apr 08, 2021 at 06:54:52PM +0300, Amir Goldstein wrote: > > They are understood to me :) but I didn't want to get into it, because > > it is complicated to explain and I wasn't sure if anyone cared... > > > > I started working on open_by_handle_at() in userns for fanotify and > > fanotify mostly reports directory fhandle, so no issues with cross-directory > renames. > > In any case, fanotify never reports "connectable" non-dir file handles. > > > > Because my proposed change ALSO makes it possible to start talking > > about userspace nfs server inside userns (in case anyone cares), I > > wanted to lay out the path towards a userspace "subtree_check" like solution. > > We have to support subdirectory exports and subtree checking because we > already have, but, FWIW, if I were writing a new NFS server from scratch, I don't > think I would. It's poorly understood, and the effort would be better spent on > more flexible storage management. Yea, nfs-ganesha does not attempt to support subtree checking. It will allow subtree exports, but it makes no assurance that they are secure. One option though that turns out to work well for them is btrfs subvols since each subvol has its own st_dev device ID, it's really as if it's a separate filesystem (and nfs-ganesha treats it as such). I'm curious about the userns solution. I'm not familiar with it, but we have issues with running nfs-ganesha inside containers due to the privileges it requires to properly run. > > Another thing I am contemplating is, if and when idmapped mount > > support is added to overlayfs, we can store an additional > > "connectable" file handle in the overlayfs index (whose key is the > > non-connectable fhandle) and fix ovl_acceptable() similar to > > nfsd_acceptable() and then we will be able to mount an overlayfs inside userns > with nfs_export support. > > > > I've included a two liner patch on the fhandle_userns branch to allow > > overlayfs inside userns with nfs_export support in the case that > > underlying filesystem was mounted inside userns, but that is not such > > an interesting use case IMO. > > > > Thanks, > > Amir.
