On 3/14/22 12:45, Martin Kletzander wrote:
[adding back libvir-list to the Cc]
On Fri, Mar 11, 2022 at 03:55:03PM +0100, Nikola Knazekova wrote:
> Hey Martin,
>
> thanks for your resposne.
>
> I don't know if it is happening in the mount namespace. Can you look
> at the
> logs in attachment?
>
> It was happening on clear install on F35, F36 and on older versions
> probably too.
> But it is only an issue in the new selinux policy for libvirt. In old
> selinux policy is allowed for virtd to unlink /dev/urandom char files.
> I just wanted to be sure if it is ok to allow it for virtqemud.
>
That actually might be the case, that it actually does set the context
on /dev/urandom correctly and then the unlink fails for virtqemud since
the selinux policy only accounts for libvirtd even though we switched to
modular daemons making virtqemud the one to do the work.
@Michal can you confirm what I'm guessing here since you did a lot of
the mount namespace work which I presume is what contributes to the
issue here.
In the meantime, would you mind trying this with the mount namespace
feature turned off in /etc/libvirt/qemu.conf like this:
namespaces = []
Yeah, this will definitely help. So, a short introduction into how
libvirt starts a QEMU guest. It creates a mount namespace so that QEMU
doesn't have access to all the files in the system. In this namespace
(which is per each QEMU process) firstly very few paths are populated
independent of guest configuration (like /dev/null, /dev/random/,
/dev/urandom, etc.) - the full list is accessible here:
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu.conf#L565
(yes, it's the cgroup_device_acl list - because what you want to enable
in CGroups you want to expose in the namespace)
Then, the paths from domain XML are created using the following function:
https://gitlab.com/libvirt/libvirt/-/blob/master/src/qemu/qemu_namespace....
This function is written in a fashion that allows files to exist and if
needed [1] it simply unlink()-s existing file and creates it from
scratch again. Now, since you configured TPM for your guest with
/dev/urandom as a backend, this node is created twice. The first time
among with other cgroup_device_acl files, the second because of TPM from
your domain config.
1: needed is probably a bad word, and in fact we can be more clever
about it. We might check whether given device already exists and if it
has the same MAJ:MIN and act accordingly. The same applies for symlinks.
Let me see if I can cook up a patch that implements this idea.
Michal