From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoItA-0007um-Ef for qemu-devel@nongnu.org; Mon, 09 Jul 2012 14:40:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoIt8-0001rt-8g for qemu-devel@nongnu.org; Mon, 09 Jul 2012 14:40:51 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:48012) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoIt7-0001qt-Vs for qemu-devel@nongnu.org; Mon, 09 Jul 2012 14:40:50 -0400 Received: from /spool/local by e1.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 9 Jul 2012 14:40:45 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 6BE026E806A for ; Mon, 9 Jul 2012 14:40:39 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q69IecP7374600 for ; Mon, 9 Jul 2012 14:40:38 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6A0BU1X025257 for ; Mon, 9 Jul 2012 20:11:31 -0400 Message-ID: <4FFB25A2.1010303@us.ibm.com> Date: Mon, 09 Jul 2012 13:40:34 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1340390174-7493-1-git-send-email-coreyb@linux.vnet.ibm.com> <20120626091004.GA14451@redhat.com> In-Reply-To: <20120626091004.GA14451@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: kwolf@redhat.com, stefanha@linux.vnet.ibm.com, libvir-list@redhat.com, Corey Bryant , qemu-devel@nongnu.org, lcapitulino@redhat.com, pbonzini@redhat.com, eblake@redhat.com 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. Perhaps we should reconsider using an RPC for QEMU to request an fd as this solves all the cited problems in a much simpler fashion. Regards, Anthony Liguori