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