On Mon, Mar 08, 2021 at 11:52:58AM +0100, Max Reitz wrote: > On 08.03.21 10:06, Sergio Lopez wrote: > > On Fri, Mar 05, 2021 at 05:22:56PM +0100, Max Reitz wrote: > > > == Summary == > > > > > > So, my current position is: > > > > > > - Bind mounts don’t help with restricting file handles to the exported > > > directory. > > > > > > - A MAC is not very elegant, and we might encounter problems where a > > > file may be moved outside of the shared directory, but remains > > > accessible (because moving a file doesn’t change its handle). > > > (If we consider that a problem. NFS evidently doesn’t, because > > > without subtree_check, it has absolutely no protection against > > > arbitrary file handles being opened (on the FS where the export > > > resides), so valid file handles always remain valid.) > > > > > > - A solution such as NFS’s subtree_check (i.e., storing the file’s > > > parent’s handle in addition to the file’s handle itself, then > > > verifying that the file does still reside in that directory when the > > > handle is opened, and then going up the tree to see whether we can > > > trace it back to the shared directory) is interesting and can perhaps > > > be considered elegant, but it requires iterating the directory the > > > file resides in when it is opened, and it will result in file handles > > > being invalidated whenever a file is moved (outside of its directory). > > > Perhaps also other issues. In any case, there are reasons why NFS has > > > basically deprecated this. > > > > > > Opinions? :) > > > > While the MAC option doesn't look too bad to me, I can't help but feel > > that we're working around a kernel (mis)feature, which is something > > that's risky and tends to backfire. > > Which misfeature do you mean exactly? That you can open arbitrary files by > specifying the right magic number (i.e. its handle)? > > That in itself is nothing we’re really working around, but rather something > that we actively want to pass through to the guest.
But I think those file handles should be constrained to some context other than the backing file system. In any case, I see Miklos has highlighted the same issue with more detail in his response, so let's follow up this conversation there to avoid dispersion. Sergio.
signature.asc
Description: PGP signature
_______________________________________________ Virtio-fs mailing list [email protected] https://listman.redhat.com/mailman/listinfo/virtio-fs
