Re: [Qemu-devel] [PATCH 2/2] i_generation / st_gen support for handle based fs driver

[Aneesh Kumar K.V]

On Fri, 5 Aug 2011 10:24:42 +0100, Stefan Hajnoczi <address@hidden> wrote:
> On Fri, Aug 5, 2011 at 7:40 AM, Aneesh Kumar K.V
> <address@hidden> wrote:
> > On Thu, 4 Aug 2011 22:57:34 +0100, Stefan Hajnoczi <address@hidden> wrote:
> >> On Thu, Aug 4, 2011 at 7:45 PM, Aneesh Kumar K.V
> >> <address@hidden> wrote:
> >> > On Thu, 4 Aug 2011 15:31:08 +0100, Stefan Hajnoczi <address@hidden> 
> >> > wrote:
> >> >> On Thu, Aug 4, 2011 at 1:03 PM, Aneesh Kumar K.V
> >> >> <address@hidden> wrote:
> >> >> > On Thu, 4 Aug 2011 12:47:42 +0100, Stefan Hajnoczi <address@hidden> 
> >> >> > wrote:
> >> >> >> On Thu, Aug 4, 2011 at 12:20 PM, Aneesh Kumar K.V
> >> >> >> <address@hidden> wrote:
> >> >> >> > On Thu, 4 Aug 2011 11:21:05 +0100, Stefan Hajnoczi 
> >> >> >> > <address@hidden> wrote:
> >> >> >> >> On Thu, Aug 4, 2011 at 11:06 AM, Harsh Prateek Bora
> >> >> >> >> <address@hidden> wrote:
> >> >> >> >> > This patch provides support for st_gen for handle based fs type 
> >> >> >> >> > server.
> >> >> >> >> > Currently the support is provided for ext4, btrfs, reiserfs and 
> >> >> >> >> > xfs.
> >> >> >> >> >
> >> >> >> >> > Signed-off-by: Harsh Prateek Bora <address@hidden>
> >> >> >> >> > ---
> >> >> >> >> >  hw/9pfs/virtio-9p-handle.c |   30 
> >> >> >> >> > ++++++++++++++++++++++++++++++
> >> >> >> >> >  1 files changed, 30 insertions(+), 0 deletions(-)
> >> >> >> >>
> >> >> >> >> Does handle-based file I/O really need to duplicate all this 
> >> >> >> >> code?  Is
> >> >> >> >> it possible to use either regular open or handle-based open from a
> >> >> >> >> single local fs codebase?
> >> >> >> >
> >> >> >> > The only details common between handle based and local based 
> >> >> >> > getversion
> >> >> >> > callback is the ioctl. Moving that into a helper may not really 
> >> >> >> > help in
> >> >> >> > this case ?.
> >> >> >>
> >> >> >> Aneesh, do you have a public virtfs tree that I can look at?  In
> >> >> >> qemu.git we don't have virtio-9p-handle.c yet, so I can't give 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 security
> >> >> models.  It just needs to use handle syscalls instead of using 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.  Except
> >> >> 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?  If so, then
> >> >> handle and local will be equivalent and duplicate code.
> >> >>
> >> >
> >> > handle require root user privileges to run. So security model with
> >> > handle fs driver doesn't make sense. We added mapped security model 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  is needed.
> >
> >>
> >> A feature that requires QEMU to run as root has really limited value.
> >> Unprivileged users cannot use the feature, so ad-hoc QEMU users are
> >> left behind.  People don't want to deploy production guests as root,
> >> may not be allowed to, or might find that their management tool
> >> doesn't support that.  So who will be able to use this feature?
> >>
> >
> > One of the main issue that handle based backend fix is the complexity
> > 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 model the
> > user credentials with which the files are created are stored in xattr
> > 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 on 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 ?. My understanding was passthrough will be preferred
option. But i may be mistaken.

-aneesh