From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOb8z-0000NU-7V for qemu-devel@nongnu.org; Mon, 23 May 2011 15:50:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOb8y-0001k8-0Q for qemu-devel@nongnu.org; Mon, 23 May 2011 15:50:25 -0400 Received: from mail-qy0-f173.google.com ([209.85.216.173]:39970) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOb8x-0001k3-Pi for qemu-devel@nongnu.org; Mon, 23 May 2011 15:50:23 -0400 Received: by qyk36 with SMTP id 36so1162371qyk.4 for ; Mon, 23 May 2011 12:50:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4DDA83C2.5060104@redhat.com> References: <4DD6B777.9020800@us.ibm.com> <4DD6C424.1020104@codemonkey.ws> <4DDA6EFA.9040501@redhat.com> <4DDA83C2.5060104@redhat.com> From: Blue Swirl Date: Mon, 23 May 2011 22:50:03 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, aliguori@us.ibm.com, Markus Armbruster , Tyler C Hicks , Corey Bryant On Mon, May 23, 2011 at 6:56 PM, Kevin Wolf wrote: > Am 23.05.2011 17:24, schrieb Markus Armbruster: >> Kevin Wolf writes: >> >>> Am 20.05.2011 21:53, schrieb Blue Swirl: >>>> On Fri, May 20, 2011 at 10:42 PM, Anthony Liguori wrote: >>>>> On 05/20/2011 02:25 PM, Blue Swirl wrote: >>>>>> >>>>>> On Fri, May 20, 2011 at 9:48 PM, Corey Bryant = =C2=A0wrote: >>>>>>> >>>>>>> sVirt provides SELinux MAC isolation for Qemu guest processes and t= heir >>>>>>> corresponding resources (image files). sVirt provides this support >>>>>>> by labeling guests and resources with security labels that are stor= ed >>>>>>> in file system extended attributes. Some file systems, such as NFS,= do >>>>>>> not support the extended attribute security namespace, which is nee= ded >>>>>>> for image file isolation when using the sVirt SELinux security driv= er >>>>>>> in libvirt. >>>>>>> >>>>>>> The proposed solution entails a combination of Qemu, libvirt, and >>>>>>> SELinux patches that work together to isolate multiple guests' imag= es >>>>>>> when they're stored in the same NFS mount. This results in an >>>>>>> environment where sVirt isolation and NFS image file isolation can = both >>>>>>> be provided. >>>>>> >>>>>> Very nice. QEMU should use this to support privilege separation. We >>>>>> already have chroot and runas switches, a new switch should convert >>>>>> all file references to fd references internally for that process. If >>>>>> this can be made transparent, this should even be the default way of >>>>>> operation. >>>>> >>>>> You mean, QEMU starts up, opens all disk images, reinvokes itself in = a >>>>> confined context, and then passes fds to the child? >>>> >>>> And exit after that, or do the same without forking. >>>> >>>> This wouldn't work now for the native CDROM devices which need to >>>> reopen the device. For that, an explicit reopen method could be added. >>>> The method could even chat with the privileged process to get that to >>>> do the reopening, but I'd leave that to libvirt and fail without it >>>> for plain QEMU. >>> >>> There are more cases where we reopen the image file. One example is the >>> 'commit' monitor command which temporarily reopens the backing file r/w= . >>> Or Christoph's patch that allows guests to toggle the write-cache >>> enabled bit. Same for live snapshots. So we'll need a solution for them >>> before doing anything like this. >>> >>> And breaking qemu without libvirt isn't really an option for me. >> >> Reopening files is evil. =C2=A0Sometimes flaws in the system call API ma= ke it >> the only option. =C2=A0You can mitigate via /dev/fd/%d, but only on some >> systems. =C2=A0The less we reopen, the better. >> >> An fd: protocol can't easily support reopen. =C2=A0So fail it. =C2=A0Thi= s doesn't >> break any existing usage. =C2=A0It's just a restriction on the new proto= col. >> Restrictions can render the new protocol useless in practice, but we're >> not "breaking qemu without libvirt" there. >> >> Perhaps we can make relax the restriction on some system by avoiding the >> reopen in a system-dependent way. > > Right, you only get the regression once libvirt starts using it (or even > worse, qemu itself, like Blue Swirl suggested). Doesn't make it much bett= er. One solution could be to add new commands which supply fresh fds while performing the operation which needs reopening: commit_fd ide0-hd0 #33 change ide1-cd0 fd:34 I don't remember the syntax for fd passing, so that part may be weird.