From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWr28-0002UY-25 for qemu-devel@nongnu.org; Tue, 22 May 2012 11:30:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWr1y-00037U-NY for qemu-devel@nongnu.org; Tue, 22 May 2012 11:29:59 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:55491) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWr1y-00034K-KL for qemu-devel@nongnu.org; Tue, 22 May 2012 11:29:50 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 May 2012 11:29:46 -0400 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id D512538C8063 for ; Tue, 22 May 2012 11:29:42 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q4MFTeZY17694820 for ; Tue, 22 May 2012 11:29:41 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q4MFTeXY024929 for ; Tue, 22 May 2012 12:29:40 -0300 Message-ID: <4FBBB0E3.8030208@linux.vnet.ibm.com> Date: Tue, 22 May 2012 11:29:39 -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> In-Reply-To: <4FBBA698.7040805@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 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. > > Kevin > 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'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"). -- Regards, Corey