From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrCfU-0000Hb-Pe for qemu-devel@nongnu.org; Wed, 10 Aug 2011 13:34:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrCfO-00050p-HS for qemu-devel@nongnu.org; Wed, 10 Aug 2011 13:34:12 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]:45752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrCfO-00050l-8F for qemu-devel@nongnu.org; Wed, 10 Aug 2011 13:34:06 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7AHBDCj015896 for ; Wed, 10 Aug 2011 13:11:13 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7AHY5Fi259900 for ; Wed, 10 Aug 2011 13:34:05 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7AHY4dE024889 for ; Wed, 10 Aug 2011 13:34:05 -0400 From: "Aneesh Kumar K.V" In-Reply-To: References: <1312452371-10375-1-git-send-email-harsh@linux.vnet.ibm.com> <1312452371-10375-3-git-send-email-harsh@linux.vnet.ibm.com> <87hb5x1kyw.fsf@skywalker.in.ibm.com> <87ei111j0j.fsf@skywalker.in.ibm.com> <87bow510el.fsf@skywalker.in.ibm.com> <878vr81hu8.fsf@skywalker.in.ibm.com> <8762mc14ck.fsf@skywalker.in.ibm.com> Date: Wed, 10 Aug 2011 23:03:58 +0530 Message-ID: <87r54t5fy1.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] i_generation / st_gen support for handle based fs driver List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Harsh Prateek Bora , qemu-devel@nongnu.org, Avi Kivity On Wed, 10 Aug 2011 16:17:22 +0100, Stefan Hajnoczi wr= ote: > On Fri, Aug 5, 2011 at 1:53 PM, Stefan Hajnoczi wrot= e: > > On Fri, Aug 5, 2011 at 12:32 PM, Aneesh Kumar K.V > > wrote: > >> On Fri, 5 Aug 2011 10:24:42 +0100, Stefan Hajnoczi wrote: > >>> On Fri, Aug 5, 2011 at 7:40 AM, Aneesh Kumar K.V > >>> wrote: > >>> > On Thu, 4 Aug 2011 22:57:34 +0100, Stefan Hajnoczi wrote: > >>> >> On Thu, Aug 4, 2011 at 7:45 PM, Aneesh Kumar K.V > >>> >> wrote: > >>> >> > On Thu, 4 Aug 2011 15:31:08 +0100, Stefan Hajnoczi wrote: > >>> >> >> On Thu, Aug 4, 2011 at 1:03 PM, Aneesh Kumar K.V > >>> >> >> wrote: > >>> >> >> > On Thu, 4 Aug 2011 12:47:42 +0100, Stefan Hajnoczi wrote: > >>> >> >> >> On Thu, Aug 4, 2011 at 12:20 PM, Aneesh Kumar K.V > >>> >> >> >> wrote: > >>> >> >> >> > On Thu, 4 Aug 2011 11:21:05 +0100, Stefan Hajnoczi wrote: > >>> >> >> >> >> On Thu, Aug 4, 2011 at 11:06 AM, Harsh Prateek Bora > >>> >> >> >> >> wrote: > >>> >> >> >> >> > This patch provides support for st_gen for handle based= fs type server. > >>> >> >> >> >> > Currently the support is provided for ext4, btrfs, reis= erfs and xfs. > >>> >> >> >> >> > > >>> >> >> >> >> > Signed-off-by: Harsh Prateek Bora > >>> >> >> >> >> > --- > >>> >> >> >> >> > =C2=A0hw/9pfs/virtio-9p-handle.c | =C2=A0 30 ++++++++++= ++++++++++++++++++++ > >>> >> >> >> >> > =C2=A01 files changed, 30 insertions(+), 0 deletions(-) > >>> >> >> >> >> > >>> >> >> >> >> Does handle-based file I/O really need to duplicate all t= his code? =C2=A0Is > >>> >> >> >> >> it possible to use either regular open or handle-based op= en from a > >>> >> >> >> >> single local fs codebase? > >>> >> >> >> > > >>> >> >> >> > The only details common between handle based and local bas= ed getversion > >>> >> >> >> > callback is the ioctl. Moving that into a helper may not r= eally help in > >>> >> >> >> > this case ?. > >>> >> >> >> > >>> >> >> >> Aneesh, do you have a public virtfs tree that I can look at?= =C2=A0In > >>> >> >> >> qemu.git we don't have virtio-9p-handle.c yet, so I can't gi= ve any > >>> >> >> >> specific feedback. > >>> >> >> > > >>> >> >> > http://repo.or.cz/w/qemu/v9fs.git for-upstream > >>> >> >> > > >>> >> >> > I should send the patchset to qemu list soon. Was waiting for= the > >>> >> >> > co-routine patches to go upstream. > >>> >> >> > >>> >> >> The handle code looks like a copy of the local backend minus se= curity > >>> >> >> models. =C2=A0It just needs to use handle syscalls instead of u= sing paths. > >>> >> >> > >>> >> >> If you treat the path as the "handle" and use regular openat(2)= , then > >>> >> >> the handle code could do what the local backend does today. =C2= =A0Except > >>> >> >> compared to the local backend it would not have security models= and be > >>> >> >> a bit slower due to extra syscalls. > >>> >> >> > >>> >> >> Is the plan to add security models to the handle backend? =C2= =A0If so, then > >>> >> >> handle and local will be equivalent and duplicate code. > >>> >> >> > >>> >> > > >>> >> > handle require root user privileges to run. So security model wi= th > >>> >> > handle fs driver doesn't make sense. We added mapped security mo= del to > >>> >> > avoid requiring user to run as root. > >>> >> > >>> >> Does it really require root or is a specific set of capabilities > >>> >> enough? > >>> > > >>> > CAP_DAC_READ_SEARCH =C2=A0is needed. > >>> > > >>> >> > >>> >> A feature that requires QEMU to run as root has really limited val= ue. > >>> >> Unprivileged users cannot use the feature, so ad-hoc QEMU users are > >>> >> left behind. =C2=A0People don't want to deploy production guests a= s root, > >>> >> may not be allowed to, or might find that their management tool > >>> >> doesn't support that. =C2=A0So who will be able to use this featur= e? > >>> >> > >>> > > >>> > One of the main issue that handle based backend fix is the complexi= ty > >>> > involved in handling renames, both on the guest and on the host. I = am > >>> > also not sure how effective it would be to run the qemu as non root= user > >>> > when exporting a directory with VirtFS. In the mapped security mode= l the > >>> > user credentials with which the files are created are stored in xat= tr > >>> > and that mostly implies host cannot look at the files the same way. > >>> > > >>> > My understanding is passthrough security model (which require qemu = to > >>> > run as root) will be used if somebody wants to export a directory o= n the > >>> > host to guest. In my case I use none security model, simply because= i > >>> > don't want new xattr on the file created and I am ok even the files > >>> > get created on the host with the credentials on qemu. > >>> > >>> With xattrs you have to mount the directory on the host in order to > >>> see the same view as the guest. > >> > >> How will that help ? There is nothing on the host that maps those xattr > >> to mode/ownership bits currently. We will have to do something similar= to fuse to > >> make that work ? > > > > Sorry, what I suggested is not actually possible today. =C2=A0We only h= ave > > a virtio-9p transport in the QEMU 9pfs code, not a TCP transport. =C2= =A0I > > meant mount -t 9p on the host - don't access the backing directory > > directly, instead mount it using 9p on localhost. > > > >> My understanding was passthrough will be preferred > >> option. But i may be mistaken. > > > > If passthrough requires all of QEMU to run as root, then we need to > > find a way to run that code separately and drop privileges in QEMU. > > > > The chroot helper process patches that Mohan posted might be a > > solution. =C2=A0The chroot helper does all path and permissions-related > > operations in a separate process. =C2=A0File descriptor passing is used= so > > that QEMU can perform read/write operations itself without copying > > data. > > > > Then we just need to make sure that QEMU itself runs unprivileged and > > the chroot helper is able to run as root for the passthrough security > > model. >=20 > Harsh, any thoughts on this? How do we achieve this ? Qemu binary should be setuid and then later drop privileges to "nobody:kvm" user:group ? or use file based capabilities because distros are removing setuid binaries ?. One nice detail about "handle" fs driver is, it won't require chroot helper at all. "handle" fs driver also work nicely with file renames on host. File rename on the guest also become much easier with "handle" tracking the file rather than the name. If we agree that running qemu as root do have security implication, then we should look at what you suggested above. I am trying to understand how distros would want to ship qemu for achieving the above goal. -aneesh