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. Thanks, Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
