From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2Osw-00074A-Va for qemu-devel@nongnu.org; Thu, 25 Jul 2013 12:59:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2Osv-00006c-I8 for qemu-devel@nongnu.org; Thu, 25 Jul 2013 12:59:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:9634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2Osv-00006T-B3 for qemu-devel@nongnu.org; Thu, 25 Jul 2013 12:59:25 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6PGxOAv021800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Jul 2013 12:59:24 -0400 Message-ID: <51F1595B.6050106@redhat.com> Date: Thu, 25 Jul 2013 18:59:07 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374530960-22031-1-git-send-email-imain@redhat.com> <1374530960-22031-2-git-send-email-imain@redhat.com> <20130724105543.GA3623@dhcp-200-207.str.redhat.com> <51F039F5.90109@redhat.com> <51F13804.4060906@redhat.com> <51F158E8.8040907@redhat.com> In-Reply-To: <51F158E8.8040907@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V6 1/3] Implement sync modes for drive-backup. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Kevin Wolf , famz@redhat.com, qemu-devel@nongnu.org, rjones@redhat.com, Ian Main , stefanha@redhat.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 25/07/2013 18:57, Eric Blake ha scritto: > On 07/25/2013 08:36 AM, Paolo Bonzini wrote: > >>> Furthermore, I'm proposing that for 1.6, we should make the >>> format argument mandatory for drive-backup. We made it >>> optional for drive-mirror, to allow for probing, but there have >>> been CVEs in the past due to probing of a raw file gone wrong. >>> We can always relax a mandatory argument into an optional one >>> in 1.7, if we decide that probing can be done safely, but we >>> can never turn an optional argument into a mandatory one once >>> the initial release bakes in the option. It would make the >>> code a lot simpler to just have a mandatory format argument, >>> instead of having to bake in and document hueristics on which >>> format is picked when the caller doesn't provide one. >> >> Probing is unsafe by definition, on the other hand we should >> allow it for consistency with the rest of the API. > > Shouldn't security trump consistency? If the image can be trusted, disallowing probing makes things more complex for the user for no reason. Also it's only on raw images that probing is unsafe. If all user-writable images are non-raw, probing is actually safe. Paolo My argument is that if probing > can be abused, it is better to have 1.6 be conservative and mandate > a format argument always; if we can later argue that some forms of > probing are safe, then for 1.7 we can relax the argument to > optional in the qapi-schema.json file and add code checks that > still mandate the argument in the instances where it is needed, but > allow probing in the remaining cases. But why are we so concerned > about allowing probing in the first place? Libvirt will ALWAYS be > passing a format, because that is the only way to avoid a security > bug; it is easier to design the format to be mandatory than it is > to reason about when probing might be safe, and there's no need to > be consistent with the security holes that are permanently baked > into older commands. > >> >> Making the format mandatory for mode != 'existing' is fine, >> though. We can relax it later. >> >> For mode = 'existing' we should allow both probing, and using an >> explicit format. > > But if you insist on allowing probing for mode='existing', then > qapi-schema.json must leave it as '*format':'str', and we are > stuck implementing the code for when format is mandatory in the C > code. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8VlaAAoJEBvWZb6bTYbyTcYP/jo6xYvm2kXQ8IdDlTGu8d0I 2h+ySv2TUg7b7KSRPlDc/pAAItbfzkxRl9lrk8m50iMtX+IwFkkFYLPv0hqRBKu2 5QA6DBmXmNkCl+2pABbTaVSwZgyKqxXExuHEMyLczX7Zutx5H9RQeo7hIU3TvhcU 5yuLyO6wgjsiWspvNlax2PZiN0ZMjil5BdQsTG4G2dxP3z9bDDjH9ZFUBStcrUTO qPuwmWWk1FvQptbK19U+pMybPX1MsDjJRVLd6QwbOTWlSn89zl5MDCXAdqJagAYj yN4cxuN5mlV4FyKTrnhb1eIfu5Wm+EwCo9YKcSc6EbvmKPCXXNh73xZKbk/1CngT WOhaHn+QLM0s0rQOIWPZtn+zZU2TqXW9kvRXL0nKF1cXqw/+Aoz6sjP/uJILcEh5 O9vkyeSYL7eM8EmozIRqL//R4puBjaqdKBCxD1yQQYC2dtizIBiLRVU4+w4mbnIk d561F2MR3UUEAfkGMPMMejL+rNyywffKvle4isT4raEHCppbb5OptK6RtllJ9jPr mLLJ+758JhMD5H5u1MiKTzE/eQtHaP0MTBrAaQJf4omKvWOfhv/jDD9lsLP0k3Ms WmivfZdQI+bGwi9vysEhbfAuAYdC6SSeTtZCaY6m8cKsJI/7CF5RhPMXVZElC4Q5 K2Fz6vhiU+HacN6pP2F6 =TyCJ -----END PGP SIGNATURE-----