On Wed, Aug 10, 2011 at 4:17 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Fri, Aug 5, 2011 at 1:53 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: >> On Fri, Aug 5, 2011 at 12:32 PM, Aneesh Kumar K.V >> <aneesh.ku...@linux.vnet.ibm.com> wrote: >>> 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 ? >> >> Sorry, what I suggested is not actually possible today. We only have >> a virtio-9p transport in the QEMU 9pfs code, not a TCP transport. I >> 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. The chroot helper does all path and permissions-related >> operations in a separate process. File 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. > > Harsh, any thoughts on this?
+ Aneesh :) Stefan
