[Virtio-fs] [libvirt PATCHv3 10/12] qemu: add code for handling virtiofsd

Stefan Hajnoczi stefanha at redhat.com
Thu Feb 6 13:46:58 UTC 2020


On Mon, Feb 03, 2020 at 07:36:09PM +0100, Ján Tomko wrote:
> [adding virtiofs list]
> 
> On Mon, Feb 03, 2020 at 04:43:51PM +0000, Daniel P. Berrangé wrote:
> > On Thu, Jan 30, 2020 at 06:06:26PM +0100, Ján Tomko wrote:
> > > Start virtiofsd for each <filesystem> device using it.
> > > 
> > > Pre-create the socket for communication with QEMU and pass it
> > > to virtiofsd.
> > > 
> > > Note that virtiofsd needs to run as root.
> > 
> > So we're not able to use  virtiofsd with the session libvirtd
> > which runs completely unprivileged ?
> > 
> 
> Not with the version of virtiofsd currently merged in the QEMU tree.
> 
> > I can understand the need to run as root if we want to support
> > chown() of files, or DAC_OVERRIDE, but I'm surprised it isn't
> > possible to run virtiofsd unprivileged & simply have a reduced
> > featureset where it can only create files as that one user.
> > 
> 
> Apart from the possibly missing features (I don't know how well
> virtiofsd internals are ready for those), current version of the
> daemon sets up namespaces and the seccomp sandbox.

Yes, running unprivileged is not a configuration that has been
investigated yet.  Today virtiofsd needs to be launched as root.

It would be interesting to rely on user namespaces to provide
unprivileged virtio-fs while still supporting more than 1 uid/gid.

I'm not a fan of using xattrs or other out-of-band information to store
guest ownership and permission information.  That is inconvenient to
manage (non-virtio-fs users of the directory won't see the right
uid/gid), reduces performance, and likely has race conditions.

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200206/2d1b1c28/attachment-0001.sig>


More information about the libvir-list mailing list