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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
