On Thu, Jun 25, 2020 at 9:55 PM Vivek Goyal <vgo...@redhat.com> wrote: > > On Thu, Jun 25, 2020 at 12:19:39PM +0900, Chirantan Ekbote wrote: > [..] > > > Chirantan, > > > > > > So you ended up renaming all "trusted", "security" and "system" xattrs? > > > Only "user" xattrs are complete passthrough? > > > > > > > No, we only rename "security" xattrs (except for selinux). > > > > > > > > IOW, security.selinux will be renamed to user.virtiofs.security.selinux > > > on host? > > > > > > > We don't relabel security.selinux because it only requires CAP_FOWNER > > in the process's user namespace and it also does its own MAC-based > > checks. Also we have some tools that label files beforehand so it > > seemed easier to leave them unchanged. > > If we rename selinux xattr also, then we can support selinux both in > guest and host and they both can have their own independent policies. >
This works as long as you don't need to support setfscreatecon, which exists to guarantee that an inode is atomically created with the correct selinux context. It's kind of possible for files with O_TMPFILE + fsetxattr + linkat but there is no equivalent for directories. You're basically forced to create the directory and then set the xattr and while it's possible to prevent other threads in the server from seeing the unfinished directories with a rwlock or similar there is no protection against power loss. If the machine loses power after the directory is created but before the selinux xattr is set then that directory will have the wrong selinux context and the guest would need to run restorecon at boot to assign the correct label. > Otherwise we either have to disable selinux on host (if we want to > support it in guest) or somehow guest and how policies will have > to know about each other and be able to work together (which will > be hard for a generic use case). Yes, I agree this is hard to do for a generic case but unfortunately the more I understand how selinux works the less I feel that it works well with a passthrough style file system. As you said it either needs to be turned off on the host or the host and guest need to work together. Chirantan
