On Fri, 5 Aug 2011 10:24:42 +0100, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Fri, Aug 5, 2011 at 7:40 AM, Aneesh Kumar K.V > <aneesh.ku...@linux.vnet.ibm.com> wrote: > > On Thu, 4 Aug 2011 22:57:34 +0100, Stefan Hajnoczi <stefa...@gmail.com> > > wrote: > >> On Thu, Aug 4, 2011 at 7:45 PM, Aneesh Kumar K.V > >> <aneesh.ku...@linux.vnet.ibm.com> wrote: > >> > On Thu, 4 Aug 2011 15:31:08 +0100, Stefan Hajnoczi <stefa...@gmail.com> > >> > wrote: > >> >> On Thu, Aug 4, 2011 at 1:03 PM, Aneesh Kumar K.V > >> >> <aneesh.ku...@linux.vnet.ibm.com> wrote: > >> >> > On Thu, 4 Aug 2011 12:47:42 +0100, Stefan Hajnoczi > >> >> > <stefa...@gmail.com> wrote: > >> >> >> On Thu, Aug 4, 2011 at 12:20 PM, Aneesh Kumar K.V > >> >> >> <aneesh.ku...@linux.vnet.ibm.com> wrote: > >> >> >> > On Thu, 4 Aug 2011 11:21:05 +0100, Stefan Hajnoczi > >> >> >> > <stefa...@gmail.com> wrote: > >> >> >> >> On Thu, Aug 4, 2011 at 11:06 AM, Harsh Prateek Bora > >> >> >> >> <ha...@linux.vnet.ibm.com> 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 <ha...@linux.vnet.ibm.com> > >> >> >> >> > --- > >> >> >> >> > 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
