Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model

[M. Mohan Kumar]

On Tuesday, September 06, 2011 08:18:22 PM Stefan Hajnoczi wrote:
 
> A virtfs feature that needs root therefore needs to be in a separate
> process.  Either QEMU needs to fork or virtfs could use a separate
> daemon binary.
> 
> You have already implemented the fork approach in the chroot patches.
> Handle-based open could work in the same way.
> 
> To summarize this architecture: all path-related operations are
> performed by a separate privileged process.  File descriptors are passed
> to QEMU over a UNIX domain socket.  This way QEMU can do the actual
> read(2)/write(2) calls directly to/from guest memory.
> 
> I think it would be nice to build a completely separate binary that QEMU
> connects to.  The separate binary would have a much smaller footprint
> (doesn't include QEMU code).  More importantly the
> privileged/unprivileged boundary would be simple and could be
> automatically set up by libvirt:
>
Hi Stefan,

Thanks for your inputs. Sorry for the delayed reply.

> $ sudo namespace_helper --sock /var/run/virtfs/1234.sock --export my_dir/
> $ qemu -fsdev local,id=my_fs,namespace_helper=/var/run/virtfs/1234.sock \
>        -device virtio-9p-pci,fsdev=my_fs

We already isolated all path related operations in a privileged process. 
Should we add this complexity? If we take this approach, for handle based 
filesystem driver, we need to ship another binary. Won't it be an usability 
issue for people who use qemu directly?