Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing

[Jeff Cody]

On Wed, Oct 29, 2014 at 08:22:16AM +0100, Markus Armbruster wrote:
> Eric Blake <address@hidden> writes:
> 
> > On 10/28/2014 12:29 PM, Jeff Cody wrote:
> [...]
> >>> What happens if more than one format tends to pick the same extension?
> >>> For example, would you consider '.qcow' a typical extension for qcow2
> >>> files, even though it would probably match the older qcow driver first?...
> >>>
> >> 
> >> I think this could arguably end up being the case for VHD and VHDX
> >> (i.e., both using .vhd).
> >> 
> >> I guess the question is, in the case of common extensions, should the
> >> priority be on the probe, or on the extension?  With the way the code
> >> is written, the priority is all going to depend on the order the
> >> driver is registered, so it may or may not warn.
> >
> > Technically, don't we correctly probe both VHD and VHDX files?  It is
> > only files that start out raw and later get mis-probed as non-raw where
> > we have an issue, so I'd rather treat the probe as accurate if it
> > matches a common extension for that format, and NOT treat the extension
> > as dictating a single required format.
> >
> >> 
> >> Currently, the code does a format probe, does an independent extension
> >> lookup, and checks if the two agree.  Instead, would it be sufficient
> >> to do the format probe, and then just verify the detected driver has a
> >> compatible extension name?
> >
> > Yes, that was what I was thinking as well.
> 
> I designed the code with the eventual removal of probing in mind:
> 
>     This should steer users away from insecure format probing.  After a
>     suitable grace period, we can hopefully drop format probing
>     alltogether.
>

Not for 'qemu-img info', or similar commands.  I can see the file name
extension, but sometimes I may want to be able to determine what a
.img file actually contains.


> The warning triggers on insecure probing.  That's one view of it.  The
> other view is it triggers when potentially insecure probing and our new
> secure guessing come up with different answers.  It serves as warning of
> future behavioral change.
> 
> If we only check the extension matches the probing, we gain support for
> ambiguous file name extensions, but make the future change warning
> incomplete.  That's bad.
> 
> If .vhd can really be two formats so different we actually want to
> separate block drivers for them, we want something more sophisticated
> than my patch.  Need to think.