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