Re: New QEMU daemon for persistent reservations

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

 



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



[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