From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPUne-0004XX-0K for qemu-devel@nongnu.org; Wed, 02 May 2012 04:20:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPUnV-0006bk-Ds for qemu-devel@nongnu.org; Wed, 02 May 2012 04:20:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39886) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPUnV-0006bd-67 for qemu-devel@nongnu.org; Wed, 02 May 2012 04:20:29 -0400 Message-ID: <4FA0EE41.6090303@redhat.com> Date: Wed, 02 May 2012 10:20:17 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1335886307-27586-1-git-send-email-stefanha@linux.vnet.ibm.com> <4FA046C6.5080909@us.ibm.com> In-Reply-To: <4FA046C6.5080909@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: libvir-list@redhat.com, Corey Bryant , Stefan Hajnoczi , qemu-devel@nongnu.org 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 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. Kevin