On Sun, Sep 10, 2017 at 11:52:24AM +0200, Paolo Bonzini wrote: > On 29/08/2017 14:41, Daniel P. Berrange wrote: > > On Tue, Aug 22, 2017 at 06:27:40PM +0200, Paolo Bonzini wrote: > >> Hi all, > >> > >> I am adding a new daemon to QEMU, that QEMU can connect to in order to > >> issue persistent reservation commands. > > > > Can you elaborate on what this daemon does ? > > > > IIUC, by 'persistent reservation' you are referring to SCSI LUN > > reservations ? If so, the security model needs to involve more > > than just policy on the socket that QEMU uses to talk to the > > PR daemon. We need to be able to control what device nodes this > > daemon is permitted to access. > > > > For iSCSI backed disks, the daemon might need to use the libiscsi > > driver, instead of assuming there is a device node on the local > > host too. > > libiscsi-backed disks can already issue persistent reservations. The > daemon is only needed for physical disks, as an alternative to > sgio='unfiltered' or (yuck) running QEMU with CAP_SYS_RAWIO. > > > Libvirt has a generic lock manager facility and I've previously > > though might be able to be extended to acquire SCSI reservations > > for disks which are backed by SCSI/iSCSI, but never tried to > > work on this. > > This is an interesting idea, but it is unrelated to this work, which is > about guests who manage the locking on their own (through peristent > reservations). Ah ok, I missed that this was about allowing the guest todo reservations itself, rather than QEMU using it for disk locking. > > I'm not sure if want to have QEMU spawning this daemon itself or not. > > Definitely not. The daemon is not suid root. > > > On the one hand if QEMU spawns the daemon, then it means the daemon > > inherits the SELinux policy of QEMU by default, so is restricted to > > only access the devices that QEMU has been granted. > > Libvirt could also give a confined policy to the helper, but there are > some complications because of multipath. When passed a multipath > device, the daemon forwards the PR command to _all_ paths, not just the > currently active one, similar to the mpathpersist(1) command. (In fact > this was the original usecase; support for non-multipath devices was > just an easy and useful extension.) > > 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 ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
