On Thu, Feb 06, 2020 at 01:46:58PM +0000, Stefan Hajnoczi wrote: > 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. I don't think these problem needs to be considered a blockers for the ablity to use as an unprivileged user. There are valid use cases for virtiofs unprivileged, which would be satisfied without needing the ability for the guest to use any UID other than the one the host user has. eg for desktop virt I run a VM as my unprivileged user and I simply want to expose my $HOME (or a subdir) to that guest for convenient file sharing. I'm using the same UID in host & guest for my login. There is no reason for virtiofsd to need to store ownership/permissions out of band. It can directly expose the host file ownership/permissions to the guest, as 9p has been able todo. My guest will simply not be able to chown() files, and will be bound by permissions as normal. I also don't think we need the same security isolation for unprivileged usage. IOW, I would simply like virtiofsd to be capable of simply disabling its use of namespaces, and any other features which are forbidden to non-root users. If guest operations on files result in EPERM that is fine. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
