[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] block: Add option to use driver whitelist even in tools
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH] block: Add option to use driver whitelist even in tools |
Date: |
Mon, 12 Jul 2021 16:44:08 +0100 |
User-agent: |
Mutt/2.0.7 (2021-05-04) |
On Mon, Jul 12, 2021 at 10:18:30AM +0200, Kevin Wolf wrote:
> Am 09.07.2021 um 19:45 hat Eric Blake geschrieben:
> > On Fri, Jul 09, 2021 at 06:41:41PM +0200, Kevin Wolf wrote:
> > > Currently, the block driver whitelists are only applied for the system
> > > emulator. All other binaries still give unrestricted access to all block
> > > drivers. There are use cases where this made sense because the main
> > > concern was avoiding customers running VMs on less optimised block
> > > drivers and getting bad performance. Allowing the same image format e.g.
> > > as a target for 'qemu-img convert' is not a problem then.
> > >
> > > However, if the concern is the supportability of the driver in general,
> > > either in full or when used read-write, not applying the list driver
> > > whitelist in tools doesn't help - especially since qemu-nbd and
> > > qemu-storage-daemon now give access to more or less the same operations
> > > in block drivers as running a system emulator.
> > >
> > > In order to address this, introduce a new configure option that enforces
> > > the driver whitelist in all binaries.
> >
> > Is it feasible that someone would want two separate lists: one for
> > qemu (which runs run efficiently) and another for tools (which ones do
> > we support at all)? As written, your patch offers no chance to
> > distinguish between the two.
>
> Possibly. However, supporting a second list would require a much larger
> code change than this patch, so I'd say this is a problem we should only
> solve when someone actually has it.
>
> > Also, is now a good time to join the bandwagon on picking a more
> > descriptive name (such as 'allow-list') for this terminology?
>
> I don't have an opinion on the time, but I do have an opinion on using a
> separate email thread for it. :-)
It isn't difficult - the word "white" adds no value in this arg
and can simply be removed entirely right now.
> Initially I tried to find a way not to use "whitelist" in the new option
> name, but that only made things inconsistent and confusing, and renaming
> the existing options is definitely out of scope for this patch.
Calling it --block-drv-list, would be consistent with the existing
--audio-drv-list. Fixing up the other existing block list args would
be nice, but should not stop use of the better name in this patch
right now.
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 :|