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
Attachment:
signature.asc
Description: PGP signature
