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