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