Re: [libvirt] [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd

On Wed, May 2, 2012 at 9:20 AM, Kevin Wolf <kwolf(a)redhat.com&gt; 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&lt;aliguori(a)us.ibm.com&gt; 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? It solves the problem of snapshot_blkdev and other operations that re-open files. Using -blockdev and hotplug for image files as file descriptors only solves the static configuration problem, not the runtime problem we get with snapshot_blkdev. That's why this approach is more powerful than -blockdev fd=N.