On 22/08/2017 18:27, 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.
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 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.
Thinking more about it, Libvirt could start the daemon on its own,
assigning a socket per virtual machine. SELinux MCS should then just
work, because the same category is assigned to the daemon instance and QEMU.
In particular, Libvirt could create the socket itself, label it, and
pass it to the daemon through the systemd socket activation protocol
(which qemu-pr-helper supports).
The XML to use the helper with a predefined socket could be:
<disk ...>
<pr mode='connect'>/path/to/unix.socket'</pr>
</disk>
while to use it with a dedicated daemon
<disk ...>
<pr mode='private'>/path/to/qemu-pr-helper</pr>
</disk>
An empty <pr mode='private'/> element can use a standard helper program
declared in qemu.conf (default /usr/libexec/qemu-pr-helper).
Paolo