On Wed, May 02, 2012 at 11:45:26AM +0200, Kevin Wolf wrote: > Am 02.05.2012 10:53, schrieb Daniel P. Berrange: > > On Wed, May 02, 2012 at 10:20:17AM +0200, Kevin Wolf wrote: > >> Am 01.05.2012 22:25, schrieb Anthony Liguori: > >>> Thanks for sending this out Stefan. > >>> > >>> On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote: > >>>> Libvirt can take advantage of SELinux to restrict the QEMU process and prevent > >>>> it from opening files that it should not have access to. This improves > >>>> security because it prevents the attacker from escaping the QEMU process if > >>>> they manage to gain control. > >>>> > >>>> NFS has been a pain point for SELinux because it does not support labels (which > >>>> I believe are stored in extended attributes). In other words, it's not > >>>> possible to use SELinux goodness on QEMU when image files are located on NFS. > >>>> Today we have to allow QEMU access to any file on the NFS export rather than > >>>> restricting specifically to the image files that the guest requires. > >>>> > >>>> File descriptor passing is a solution to this problem and might also come in > >>>> handy elsewhere. Libvirt or another external process chooses files which QEMU > >>>> is allowed to access and provides just those file descriptors - QEMU cannot > >>>> open the files itself. > >>>> > >>>> This series adds the -open-hook-fd command-line option. Whenever QEMU needs to > >>>> open an image file it sends a request over the given UNIX domain socket. The > >>>> response includes the file descriptor or an errno on failure. Please see the > >>>> patches for details on the protocol. > >>>> > >>>> The -open-hook-fd approach allows QEMU to support file descriptor passing > >>>> without changing -drive. It also supports snapshot_blkdev and other commands > >>>> that re-open image files. > >>>> > >>>> Anthony Liguori<aliguori@xxxxxxxxxx> wrote most of these patches. I added a > >>>> demo -open-hook-fd server and added some small fixes. Since Anthony is > >>>> traveling right now I'm sending the RFC for discussion. > >>> > >>> What I like about this approach is that it's useful outside the block layer and > >>> is conceptionally simple from a QEMU PoV. We simply delegate open() to libvirt > >>> and let libvirt enforce whatever rules it wants. > >>> > >>> This is not meant to be an alternative to blockdev, but even with blockdev, I > >>> think we still want to use a mechanism like this even with blockdev. > >> > >> What does it provide on top? > >> > >> This doesn't look like something that I'd like a lot. qemu should be > >> able to continue to run no matter what the management tool does, whether > >> it responds to RPCs properly or whether it has crashed. You need a > >> really good use case for the RPC that cannot be covered otherwise in > >> order to justify this. > > > > Indeed, this solution breaks if you stop or restart libvirtd while > > QEMU is running. Restarting libvirt while QEMU is running is something > > we must support, since installing RPM updates will restart libvirtd > > and we cannot let guests die in this case. > > > > I would much prefer to see us be able to pass FDs in directly alongside > > the disk config as we do for netdev TAP/etc, and for QEMU / kernel to be > > fixed so that you do not need to re-open FDs on the fly. > > I agree, and this is what -blockdev would give us. > > Part of why I don't like the RFC (apart from RPCing the management tool > being just wrong) is that once again it's trying to take shortcuts and > only provide a hack for the urgent need instead of doing it properly and > implementing -blockdev. I suspect that if we take something half-baked > like this, we will keep being unhappy with the situation in the block > layer, but it won't hurt enough any more to actually spend effort on it, > so that we'll go another five years with it. I tend to agree - we have been talking about -blockdev for faar to long without (AFAICT) making any real progress towards getting it done. I'd love to see someone bite the bullet & have a go at implementing it Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list