[libvirt] New QEMU daemon for persistent reservations

[Daniel P. Berrange]

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.

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.

> The daemon can only issue the commands on file descriptor that QEMU
> already has.  In addition normal users shouldn't have access to the
> daemon's Unix socket in /run, so the daemon is protected against misuse.
> 
> My question is what is the best way to handle the connection to the
> daemon socket.  Currently, the path to the socket is passed to QEMU on
> the command line:
> 
>  -object pr-manager-helper,id=mgr,path=/run/qemu-pr-helper.sock \
>  -drive if=none,id=hd,driver=raw,filename=/dev/sdb,file.pr-manager=mgr \
>  -device scsi-block,drive=hd
> 
> (the new parts are "-object pr-manager-helper" and "file.pr-manager").

I'm not sure if want to have QEMU spawning this daemon itself or not.

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. On the other
hand, this means we need to give QEMU permission to execve(), which
is something we've been striving to remove by default.

> I could just make it root:root and pass a file descriptor from libvirt
> to QEMU, but this would make it impossible for QEMU to reconnect to the
> daemon in case someone does a "systemctl restart" or even just kills it
> inadvertently.  The daemon is stateless, so transparent reconnection
> would be a nice feature to have.
> 
> The alternative is to somehow label the daemon socket so that it can be
> accessed by QEMU, but I'm not very well versed in SELinux.
> 
> Any ideas?

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