Dear list,
lately I was confronted with the way how KubeVirt uses libvirt. They run
it inside a docker container with UID mapping and some capabilities
dropped. See [1] for more info. Problem is that because of the way we
initialize our defaults they had to disable some features. Specifically,
virQEMUDriverConfigNew() is passed @privileged argument which equals
geteuid() == 0. Apparently, due to UID mapping this leads us to create
not valid defaults. For instance, rememberOwner will be set to true in
this case, but trying to write any XATTR is going to fail because the
container and subsequently libvirtd does have CAP_SYS_ADMIN (and writing
trusted.* XATTRs is reserve to CAP_SYS_ADMIN). Similarly,
dynamicOwnership won't work unless CAP_CHOWN is granted and if SELinux
driver is enabled then we will also need CAP_SYS_ADMIN because
setfilecon_raw() does nothing more than write XATTR [2].
So instead of using @privileged we could use capabilities to
enable/disable features by default. There is one problem with this
though - do we know the full set of capabilities we need for given
feature? For instance, does rememberOwner needs just CAP_SYS_ADMIN or
also some other capability?
Users could still override our defaults through qemu.conf, but I can see
us throwing a warning if they are trying to enable say rememberOwner
while the libvird lacks CAP_SYS_ADMIN.
What is your opinion?
Michal
1: https://bugzilla.redhat.com/show_bug.cgi?id=1774373#c17
2:
https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/setfilecon.c#L10
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
