On 30/05/19 12:08, Michal Privoznik wrote:
1) Try to acquire (lock) pidfile
2) unlink(socket)
3) spawn pr-helper process (this yields child's PID)
4) wait some time until socket is created
5) some follow up work (move child's PID into same cgroup as qemu's main
thread, relabel the socket so that qemu can access it)
Note that qemu-pr-helper supports the systemd socket activation
protocol. Would it help if libvirt used it?
Thing is, libvirt creates a mount namespace for domains (one namespace
for one domain). In this namespace a dummy /dev is mounted and only
nodes that qemu is configured to have are created. For instance, you
won't see /dev/sda there unless your domain has it as a disk. Then,
libvirt moves pr-helper process into the same cgroups as the qemu's main
thread. This is all done so that pr-helper has the same view of the
system as qemu. I don't think that he same result can be achieved using
socket activation.
Why? The only difference with "normal" behavior and socket activation
is who creates the socket and calls listen() on it. Everything else is
entirely the same.
Also, libvirt spawns one pr-helper per domain (so that the socket can be
private and share seclabel with qemu process it's attached to).
Yes, that is why I thought the socket could be moved in advance to the
right security label, prior to exec. Also, perhaps could the child move
itself to the right cgroup before dropping privileges. This would
remove the window between 3 and 5, by moving all the work *before*
qemu-pr-helper is exec-ed.
Paolo
.