From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWrYk-00019y-Qn for qemu-devel@nongnu.org; Tue, 22 May 2012 12:03:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWrYe-0005PR-78 for qemu-devel@nongnu.org; Tue, 22 May 2012 12:03:42 -0400 Received: from e7.ny.us.ibm.com ([32.97.182.137]:36362) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWrYe-0005OV-2p for qemu-devel@nongnu.org; Tue, 22 May 2012 12:03:36 -0400 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 May 2012 12:03:31 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 561656E808B for ; Tue, 22 May 2012 12:02:30 -0400 (EDT) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4MG2Tt7106114 for ; Tue, 22 May 2012 12:02:29 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4MG2CvZ027561 for ; Tue, 22 May 2012 10:02:13 -0600 Message-ID: <4FBBB880.9070000@linux.vnet.ibm.com> Date: Tue, 22 May 2012 12:02:08 -0400 From: Corey Bryant MIME-Version: 1.0 References: <1337631598-30639-1-git-send-email-coreyb@linux.vnet.ibm.com> <4FBB4BCE.5080905@redhat.com> <4FBBA2F8.1020300@linux.vnet.ibm.com> <4FBBA698.7040805@redhat.com> <4FBBB0E3.8030208@linux.vnet.ibm.com> <4FBBB327.1000208@redhat.com> In-Reply-To: <4FBBB327.1000208@redhat.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 0/4] block: file descriptor passing using -filefd and getfd_file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: libvir-list@redhat.com, aliguori@us.ibm.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com On 05/22/2012 11:39 AM, Kevin Wolf wrote: > Am 22.05.2012 17:29, schrieb Corey Bryant: >> >> >> On 05/22/2012 10:45 AM, Kevin Wolf wrote: >>> Am 22.05.2012 16:30, schrieb Corey Bryant: >>>> >>>> >>>> On 05/22/2012 04:18 AM, Kevin Wolf wrote: >>>>> Am 21.05.2012 22:19, schrieb Corey Bryant: >>>>>> libvirt's sVirt security driver provides SELinux MAC isolation for >>>>>> Qemu guest processes and their corresponding image files. In other >>>>>> words, sVirt uses SELinux to prevent a QEMU process from opening >>>>>> files that do not belong to it. >>>>>> >>>>>> sVirt provides this support by labeling guests and resources with >>>>>> security labels that are stored in file system extended attributes. >>>>>> Some file systems, such as NFS, do not support the extended >>>>>> attribute security namespace, and therefore cannot support sVirt >>>>>> isolation. >>>>>> >>>>>> A solution to this problem is to provide fd passing support, where >>>>>> libvirt opens files and passes file descriptors to QEMU. This, >>>>>> along with SELinux policy to prevent QEMU from opening files, can >>>>>> provide image file isolation for NFS files. >>>>>> >>>>>> This patch series adds the -filefd command-line option and the >>>>>> getfd_file monitor command. This will enable libvirt to open a >>>>>> file and push the corresponding filename and file descriptor to >>>>>> QEMU. When QEMU needs to "open" a file, it will first check if the >>>>>> file descriptor was passed by either of these methods before >>>>>> attempting to actually open the file. >>>>> >>>>> I thought we decided to avoid making some file names magic, and instead >>>>> go for the obvious /dev/fd/42? >>>> >>>> I understand that open("/dev/fd/42") would be the same as dup(42), but >>>> I'm not sure that I'm entirely clear on how this would work. Could you >>>> give an example? >>> >>> With your approach you open the file outside qemu, pass the fd to qemu >>> along with a file name that it's supposed to replace and then you use >>> that fake file name: >>> >>> (qemu) getfd_file abc >>> (qemu) drive_add 0 file=abc,... >>> >>> Instead you could use the existing getfd command and avoid the translation: >>> >>> (qemu) getfd >>> 42 >>> (qemu) drive_add 0 file=/dev/fd/42,... >>> >>> Er, well. Just that getfd doesn't return the assigned fd today, so the >>> management tool doesn't know it. We would have to add that. >> >> Thanks for the explanation. This would mean the management app that >> performs the open(/path/to/my.img) would have to keep a mapping of >> filenames (/path/to/my.img) to corresponding /dev/fd/X paths, or perhaps >> just keeping track of the filename and fd is enough. It sounds like >> this would simplify things in QEMU and get rid of any need for >> canonicalization of filenames in QEMU. > > I don't know the implementation details of libvirt, but I would assume > that they don't have to keep a name/fd map and deal with strings, but > could just add the fd to some internal object representing a block > device of a running domain. I would be surprised if this didn't exist. > Ok, that's probably the case. >> I'm not sure why getfd would have to return the fd though. I'm assuming >> this would be the fd returned from open("dev/fd/42"). > > It would be the 42. When you pass a file descriptor via getfd, you don't > know yet which number it gets assigned in qemu. > > Kevin > Sorry, I must be missing something. Isn't 42 the fd that libvirt got from the open() call? I assume you are talking about returning the fd that QEMU created as a dup. I'm still not seeing the point in returning an fd to libvirt. It seems like QEMU should just be able to dup the fd that it was passed, and close/re-dup it as needed. -- Regards, Corey