From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R38oN-0008MH-AP for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:52:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R38oM-00033y-85 for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:52:43 -0400 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:36390) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R38oL-0002yC-Jl for qemu-devel@nongnu.org; Mon, 12 Sep 2011 11:52:42 -0400 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by e28smtp04.in.ibm.com (8.14.4/8.13.1) with ESMTP id p8CFqVhc029474 for ; Mon, 12 Sep 2011 21:22:31 +0530 Received: from d28av04.in.ibm.com (d28av04.in.ibm.com [9.184.220.66]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8CFqUVp340222 for ; Mon, 12 Sep 2011 21:22:30 +0530 Received: from d28av04.in.ibm.com (loopback [127.0.0.1]) by d28av04.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8CFqUMu005870 for ; Tue, 13 Sep 2011 01:52:30 +1000 From: "M. Mohan Kumar" Date: Mon, 12 Sep 2011 19:45:04 +0530 References: <1315239516-4451-1-git-send-email-mohan@in.ibm.com> <20110906144822.GA27940@stefanha-thinkpad.localdomain> In-Reply-To: <20110906144822.GA27940@stefanha-thinkpad.localdomain> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109121945.04717.mohan@in.ibm.com> Subject: Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: qemu-devel@nongnu.org On Tuesday, September 06, 2011 08:18:22 PM Stefan Hajnoczi wrote: > A virtfs feature that needs root therefore needs to be in a separate > process. Either QEMU needs to fork or virtfs could use a separate > daemon binary. > > You have already implemented the fork approach in the chroot patches. > Handle-based open could work in the same way. > > To summarize this architecture: all path-related operations are > performed by a separate privileged process. File descriptors are passed > to QEMU over a UNIX domain socket. This way QEMU can do the actual > read(2)/write(2) calls directly to/from guest memory. > > I think it would be nice to build a completely separate binary that QEMU > connects to. The separate binary would have a much smaller footprint > (doesn't include QEMU code). More importantly the > privileged/unprivileged boundary would be simple and could be > automatically set up by libvirt: > Hi Stefan, Thanks for your inputs. Sorry for the delayed reply. > $ sudo namespace_helper --sock /var/run/virtfs/1234.sock --export my_dir/ > $ qemu -fsdev local,id=my_fs,namespace_helper=/var/run/virtfs/1234.sock \ > -device virtio-9p-pci,fsdev=my_fs We already isolated all path related operations in a privileged process. Should we add this complexity? If we take this approach, for handle based filesystem driver, we need to ship another binary. Won't it be an usability issue for people who use qemu directly?