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