From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LKcdX-0006Lg-1Y for qemu-devel@nongnu.org; Wed, 07 Jan 2009 12:56:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LKcdW-0006KP-3u for qemu-devel@nongnu.org; Wed, 07 Jan 2009 12:56:10 -0500 Received: from [199.232.76.173] (port=50217 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LKcdW-0006KH-06 for qemu-devel@nongnu.org; Wed, 07 Jan 2009 12:56:10 -0500 Received: from mx2.redhat.com ([66.187.237.31]:42382) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LKcdV-0006Xe-Et for qemu-devel@nongnu.org; Wed, 07 Jan 2009 12:56:09 -0500 Message-ID: <4964ECB1.5080509@redhat.com> Date: Wed, 07 Jan 2009 19:56:01 +0200 From: Uri Lublin MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qemu: block.c: introducing "fmt:FMT:" prefix to image-filenames References: <49616228.4030608@redhat.com> <4964DE75.1010502@codemonkey.ws> In-Reply-To: <4964DE75.1010502@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Shahar Frank , Uri Lublin , qemu-devel@nongnu.org Anthony Liguori wrote: > Uri Lublin wrote: >> Hello, >> >> This patch below can be considered as a version 2 of Shahar's "Qemu >> image over raw devices" patch >> http://lists.gnu.org/archive/html/qemu-devel/2008-12/msg01083.html >> >> I think we've fixed the security flaw (that was discovered but not >> introduced by Shahar's patch). > > Doesn't the fmt= option to the block drivers achieve the same thing > (except for not probing the backend formats)? It does only for the leaf image (the writeable one). While all backing files would be probed. For example if we have a raw format image A (the base image), and the guest writes a fake qcow2 header into the beginning of the disk, and then the VM owner asks to create a new qcow2 image B with A as its backing file. In this scenario qemu opens A as a qcow2 image. This scenario is a security breach (mentioned by Daniel P. Berrange) as the fake qcow2 header may point to any host file. I need to send a second version (-cdrom is broken). Comments about the concept would be appreciated. Thanks for looking at it, Uri.