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

[Markus Armbruster]

Jeff Cody <address@hidden> writes:

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

That's a file(1) job.  But since the security argument doesn't apply to
"qemu-img info", regressing its functionality would be hard to justify.
In short, you're right.