On Fri, Jun 19, 2020 at 4:27 AM Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Jun 18, 2020 at 08:16:55PM +0100, Dr. David Alan Gilbert wrote: > > * Vivek Goyal (vgo...@redhat.com) wrote: > > > On Thu, Apr 16, 2020 at 05:49:05PM +0100, Stefan Hajnoczi wrote: > > > > virtiofsd doesn't need of all Linux capabilities(7) available to root. > > > > Keep a > > > > whitelisted set of capabilities that we require. This improves > > > > security in > > > > case virtiofsd is compromised by making it hard for an attacker to gain > > > > further > > > > access to the system. > > > > > > Hi Stefan, > > > > > > I just noticed that this patch set breaks overlayfs on top of virtiofs. > > > > > > overlayfs sets "trusted.overlay.*" and xattrs in trusted domain > > > need CAP_SYS_ADMIN. > > >
Not just that but it needs CAP_SYS_ADMIN in the init namespace[1]. We have the same problem. Our virtiofs process has CAP_SYS_ADMIN in a user namespace and it cannot set any trusted or security xattrs. The security xattrs check is at least namespace aware so you only need CAP_SYS_ADMIN in the namespace that mounted the fs but that doesn't help us much. We ended up working around it by prefixing "user.virtiofs." to the xattr name[2], which has its own problems but there was pretty much no chance that we would be able to give the fs device CAP_SYS_ADMIN in the init namespace. [1]: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/5e857ce6eae7ca21b2055cca4885545e29228fe2/fs/xattr.c#116 [2]: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2243111
