From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49917) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XkEP9-0004md-59 for qemu-devel@nongnu.org; Fri, 31 Oct 2014 11:47:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjqFX-0006kx-Ld for qemu-devel@nongnu.org; Thu, 30 Oct 2014 09:58:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjqFX-0006kr-Ca for qemu-devel@nongnu.org; Thu, 30 Oct 2014 09:58:51 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9UDwoaq015070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 30 Oct 2014 09:58:50 -0400 Date: Thu, 30 Oct 2014 09:58:47 -0400 From: Jeff Cody Message-ID: <20141030135847.GE26767@localhost.localdomain> References: <1414512220-19058-1-git-send-email-armbru@redhat.com> <1414512220-19058-3-git-send-email-armbru@redhat.com> <544FCC40.2020008@redhat.com> <20141028182955.GB26767@localhost.localdomain> <544FE6E5.6030605@redhat.com> <87wq7jibmf.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wq7jibmf.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Wed, Oct 29, 2014 at 08:22:16AM +0100, Markus Armbruster wrote: > Eric Blake 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.