qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH] pr-manager-helper: fix pr process


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] pr-manager-helper: fix pr process been killed when reconectting
Date: Thu, 30 May 2019 12:59:05 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]