[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend |
Date: |
Wed, 21 Jun 2023 16:28:33 +0100 |
User-agent: |
Mutt/2.2.9 (2022-11-12) |
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 :|
Re: [PATCH v3] 9pfs: deprecate 'proxy' backend, Daniel P . Berrangé, 2023/06/21