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

[Christian Schoenebeck]

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?

Best regards,
Christian Schoenebeck