From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlCfv-0001bU-CL for qemu-devel@nongnu.org; Mon, 03 Nov 2014 03:07:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlCfp-0005RP-6X for qemu-devel@nongnu.org; Mon, 03 Nov 2014 03:07:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44376) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlCfo-0005RJ-Ur for qemu-devel@nongnu.org; Mon, 03 Nov 2014 03:07:37 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA387aGK026309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 3 Nov 2014 03:07:36 -0500 From: Markus Armbruster 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> <20141030135847.GE26767@localhost.localdomain> Date: Mon, 03 Nov 2014 09:07:34 +0100 In-Reply-To: <20141030135847.GE26767@localhost.localdomain> (Jeff Cody's message of "Thu, 30 Oct 2014 09:58:47 -0400") Message-ID: <871tpk3dx5.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain 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: Jeff Cody Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Jeff Cody writes: > 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. 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.