[libvirt] New QEMU daemon for persistent reservations
Daniel P. Berrange
berrange at redhat.com
Mon Sep 11 10:46:28 UTC 2017
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 :|
More information about the libvir-list
mailing list