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