Re: [PATCH v3] 9pfs: deprecate 'proxy' backend

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jun 21, 2023 at 04:27:04PM +0200, Christian Schoenebeck wrote:
> On Wednesday, June 21, 2023 3:46:39 PM CEST Daniel P. Berrangé wrote:
> > On Sat, Jun 10, 2023 at 03:39:44PM +0200, Christian Schoenebeck wrote:
> > > +``-fsdev proxy`` and ``-virtfs proxy`` (since 8.1)
> > > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > > +
> > > +The 9p ``proxy`` filesystem backend driver has been deprecated and will be
> > > +removed in a future version of QEMU. Please use ``-fsdev local`` or
> > > +``-virtfs local`` for using the ``local`` 9p filesystem backend instead.
> > > +
> > > +The 9p ``proxy`` backend was originally developed as an alternative to the 9p
> > > +``local`` backend. The idea was to enhance security by dispatching actual low
> > > +level filesystem operations from 9p server (QEMU process) over to a separate
> > > +process (the virtfs-proxy-helper binary). However this alternative never gained
> > > +momentum. The proxy backend is much slower than the local backend, hasn't seen
> > > +any development in years, and showed to be less secure, especially due to the
> > > +fact that its helper daemon must be run as root, whereas with the local backend
> > > +QEMU is typically run as unprivileged user and allows to tighten behaviour by
> > > +mapping permissions et al.
> > 
> > The fact that the helper daemon runs as root was actually an intentional
> > design choice to improve security. When QEMU is running unprivileged, the
> > 'local' backend is limited in what it can serve to stuff that is readable/
> > writable by the 'qemu' user account.
> > 
> > Using the 'proxy' backend allowed that restriction to be lifted, such
> > that it can serve files owned by arbitrary users.
> > 
> > Yes, the 'proxy' backend is less secure than the 'local' backend in an
> > unprivileged QEMU. It is massively more secure, however, than the 'local'
> > backend in a QEMU process running as root, which was the only option if
> > you need to serve files for many users.
> > 
> > IOW, if someone is currently using the 'proxy' backend, the 'local' backend
> > is quite likely NOT a viable alternative.
> 
> Depends. Some people just want to dump few files between host <-> guest, they
> should even be fine with unpriviliged 'passhthrough' security model with the
> 'local' backend.
> 
> For more complex use cases, you would probably transition to 'mapped' security
> model with the 'local' backend. That's like transitioning from one file system
> to another, mounting the two, copying over once, that's it.
> 
> > I'm fine with deprecating this. In terms of messaging wrt replacements,
> > we should highlight both the 9p 'local' backend, and virtiofsd as the
> > two alternatives. The latter is likely the better choice (on linux
> > hosts) for many.
> 
> OK, I can add that to the deprecation doc, but you don't want that to be
> added to all the runtime warnings as well, do you?

I'd suggest we could do mention it briefly as an option at rutime, eg

warn_report("'-virtfs proxy' is deprecated, use '-virtfs local' or virtiofs instead");


With 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 :|