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