From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrPVS-0003SC-8h for qemu-devel@nongnu.org; Thu, 11 Aug 2011 03:16:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrPVO-0000nl-4Y for qemu-devel@nongnu.org; Thu, 11 Aug 2011 03:16:42 -0400 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:56196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrPVN-0000nD-B0 for qemu-devel@nongnu.org; Thu, 11 Aug 2011 03:16:38 -0400 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp05.au.ibm.com (8.14.4/8.13.1) with ESMTP id p7B79oIw024246 for ; Thu, 11 Aug 2011 17:09:50 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p7B7FL5u1056794 for ; Thu, 11 Aug 2011 17:15:21 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p7B7GLnF032291 for ; Thu, 11 Aug 2011 17:16:21 +1000 Message-ID: <4E4381C3.2030707@linux.vnet.ibm.com> Date: Thu, 11 Aug 2011 12:46:19 +0530 From: Harsh Bora MIME-Version: 1.0 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Avi Kivity , "Aneesh Kumar K.V" , qemu-devel@nongnu.org On 08/10/2011 08:47 PM, Stefan Hajnoczi wrote: > On Fri, Aug 5, 2011 at 1:53 PM, Stefan Hajnoczi wrote: >> 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, reiserfs and xfs. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Harsh Prateek Bora >>>>>>>>>>>>> --- >>>>>>>>>>>>> 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? Hi Stefan, I am still not sure if it is really a big concern for VirtFS users, and if really required, we can move the functionality to a privileged process and but that would require Qemu to be initially run as root and then drop privileges to a certain non-root user. However, lets take this discussion separately and see what community thinks about it. If the community agrees, we can do it when we merge the chroot patch series. I therefore posted v2 for the st_gen patch to keep that isolated. - Harsh > > Stefan