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. It also worries me the fact that we'd need to run virtiofsd with CAP_DAC_READ_SEARCH. IIUC, we need this to avoid the need to keep an FD open for each entry that's in the Guest's lookup cache, which is something that's probably going to become a problem once we have dozens of virtiofsd instances servicing VMs on the same Host (BTW, this is already a problem on macOS, where the default *system-wide* NOFILE limit is a little over 10,000). Perhaps we should try to aim higher and propose some kernel extensions that would fit better our needs? Thanks, Sergio.