From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoWDu-0007iG-Rv for qemu-devel@nongnu.org; Tue, 10 Jul 2012 04:55:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoWDk-0005Ze-Cb for qemu-devel@nongnu.org; Tue, 10 Jul 2012 04:55:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64862) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoWDk-0005ZV-4Q for qemu-devel@nongnu.org; Tue, 10 Jul 2012 04:55:00 -0400 Date: Tue, 10 Jul 2012 09:54:46 +0100 From: "Daniel P. Berrange" Message-ID: <20120710085446.GA23460@redhat.com> References: <1340390174-7493-1-git-send-email-coreyb@linux.vnet.ibm.com> <20120626091004.GA14451@redhat.com> <4FFB25A2.1010303@us.ibm.com> <20120709160037.66fdda12@doriath.home> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120709160037.66fdda12@doriath.home> Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: kwolf@redhat.com, Anthony Liguori , stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, Corey Bryant , qemu-devel@nongnu.org, pbonzini@redhat.com, eblake@redhat.com On Mon, Jul 09, 2012 at 04:00:37PM -0300, Luiz Capitulino wrote: > On Mon, 09 Jul 2012 13:40:34 -0500 > Anthony Liguori wrote: > > > On 06/26/2012 04:10 AM, Daniel P. Berrange wrote: > > > On Fri, Jun 22, 2012 at 02:36:07PM -0400, Corey Bryant wrote: > > >> 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 stored on the same NFS > > >> mount. > > >> > > >> This patch series adds the pass-fd QMP monitor command, which allows > > >> an fd to be passed via SCM_RIGHTS, and returns the received file > > >> descriptor. Support is also added to the block layer to allow QEMU > > >> to dup the fd when the filename is of the /dev/fd/X format. This > > >> is useful if MAC policy prevents QEMU from opening specific types > > >> of files. > > > > > > I was thinking about some of the sources complexity when using > > > FD passing from libvirt and wanted to raise one idea for discussion > > > before we continue. > > > > > > With this proposed series, we have usage akin to: > > > > > > 1. pass_fd FDSET={M} -> returns a string "/dev/fd/N" showing QEMU's > > > view of the FD > > > 2. drive_add file=/dev/fd/N > > > 3. if failure: > > > close_fd "/dev/fd/N" > > > > > > My problem is that none of this FD passing is "transactional". > > > > My original patch series did not suffer from this problem. > > > > QEMU owned the file descriptor once it received it from libvirt. > > > > I don't think the cited problem (QEMU failing an operation if libvirt was down) > > is really an actual problem since it would be libvirt that would be issuing the > > command in the first place (so the command would just fail which libvirt would > > have to assume anyway if it crashed). > > > > I really dislike where this thread has headed with /dev/fdset. This has become > > extremely complex and cumbersome. > > I agree, maybe it's time to start over and discuss the original problem again. I must say, I'm not entirely sure of all the problems we're trying to solve anymore. I don't think we've ever clearly stated in this thread what all the requirements/problems are, so I'm finding it hard to see what the optimal solution is. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|