Re: [libvirt] New QEMU daemon for persistent reservations
On 11/09/2017 12:46, Daniel P. Berrange wrote:
> So the helper is a bit different from QEMU with respect to both
SELinux
> MCS labeling and the devices cgroup. Access limitation comes from only
> ever operating on devices that have been passed on the socket. SELinux
> MCS could be used so that only the "right" QEMU can connect to each
> instance of the helper, though.
I wonder how this interacts with SELinux. IIUC if we grant access to
the multipath device file, the kernel won't normally require us to
grant access the underlying paths. I/O is just allowed because they
are a member of the mpath device. Hopefully this applies to the
persistent reservations too ?
No, persistent reservations are special; they have to be registered
independently on each path. (As I said, this was the original reason to
have a separate daemon: implementing it in QEMU would be not just a bad
idea because you need CAP_SYS_ADMIN, it would be impossible for
libvirt-started guests because of sVirt and device cgroups).
So I think the helper daemon needs to be granted blanket ioctl access to
devices, without using either device cgroups or MCS.
Paolo