From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48684) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWrBS-0007Si-69 for qemu-devel@nongnu.org; Tue, 22 May 2012 11:39:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWrBL-0006qS-PM for qemu-devel@nongnu.org; Tue, 22 May 2012 11:39:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWrBL-0006qA-Ga for qemu-devel@nongnu.org; Tue, 22 May 2012 11:39:31 -0400 Message-ID: <4FBBB327.1000208@redhat.com> Date: Tue, 22 May 2012 17:39:19 +0200 From: Kevin Wolf 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> In-Reply-To: <4FBBB0E3.8030208@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-15 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: Corey Bryant Cc: libvir-list@redhat.com, aliguori@us.ibm.com, eblake@redhat.com, qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com 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. > 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