[PATCH 4/4] util: qcow2GetExtensions: Remove support for 'data file' extension
pkrempa at redhat.com
Mon Apr 27 09:38:32 UTC 2020
On Fri, Apr 24, 2020 at 10:25:15 -0500, Eric Blake wrote:
> On 4/24/20 10:18 AM, Peter Krempa wrote:
> > On Fri, Apr 24, 2020 at 09:52:00 -0500, Eric Blake wrote:
> > > On 4/24/20 4:24 AM, Peter Krempa wrote:
> > > > The implementation was never finished in libvirt. Remove it.
> > > >
> > > > Signed-off-by: Peter Krempa <pkrempa at redhat.com>
> > > > ---
> > > > src/util/virstoragefile.c | 19 ++-----------------
> > > > 1 file changed, 2 insertions(+), 17 deletions(-)
> > >
> > > Shouldn't we at least recognize if there is a qcow2 file with the extension
> > > header set, at which point we can error out and tell the user their image is
> > > unsupported, rather than trying to use it without the data file?
> > I don't think it's scalable to do so unless qemu exposes a whitelist of
> > supported extensions we can declare we support. Otherwise we are
> > band-aiding stuff we lear that exists and ignore any other extensions.
> external data files have an incompatible feature bit set in addition to the
> header extension. Maybe whitelisting header extensions is prohibitive, but
> we should be able to recognize when a qcow2 file has an incompatible feature
> bit set that we are not aware of, and assume that since we don't know about
> the feature, we also don't know how to safely pass that file to qemu.
> That is, we could quickly reject qcow2 files with offset 72-79 containing
> bit 2 set, until we are ready to support external data files in libvirt.
Are there any specific reasons to do so? If so we should track them in a
bug/issue in the first place. Additionally I'm against extending the
qcow2 header parser beyond what's strictly necessary. In the end our
reimplementation of of the parser is considered a security measure.
I've pushed the patches for now. If somebody will require the 'data
file' field the last patch can always be reverted.
More information about the libvir-list