Re: New QEMU daemon for persistent reservations

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

 



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



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux