Re: [libvirt] New QEMU daemon for persistent reservations

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).

> 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.