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

Re: [libvirt] New QEMU daemon for persistent reservations

On 27/11/2017 11:59, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 11:57:56AM +0100, Paolo Bonzini wrote:
>> On 27/11/2017 10:40, Daniel P. Berrange wrote:
>>> If we had one daemon per QEMU, then we would give the daemon the same
>>> MCS label as QEMU. The kernel will thus enforce this label matches the
>>> label on the QEMU process when it connects to the UNIX socket. The kernel
>>> will also validate the label on the disk file descriptor passed to the
>>> daemon by QEMU.
>>> If we had one daemon per host, then that daemon will need a generic
>>> label that lets all QEMUs connect to it. When QEMU passes in a disk
>>> FD, the daemon will need to query the SELinux context of the remote
>>> QEMU process, and then perform a userspace ACL check of that against
>>> the FD that is passed in.
>>> The latter case means the QEMU helper will need to link to libselinux
>>> and performs checks itself.
>> Then it seems much better to use one daemon per QEMU, indeed.
> That would rule out using persistent reservations for unprivileged QEMU
> though, because we still need sVirt protection for that.

Hm, I see what you mean now.  But it would be "just" a qemu-pr-helper
bug that it trusts the caller to have "ioctl" permissions on the file
descriptor, wouldn't it?

And it could be a feature even, since the remote QEMU process also has
to have "connect" permissions on the qemu-pr-helper socket.  So you
could give it ioctl access *limited to persistent reservations* by
granting the appropriate permissions on the socket.



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