From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1IJER5-00021a-B9
	for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:16:47 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1IJER3-00020p-M9
	for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:16:46 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1IJER3-00020k-F6
	for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:16:45 -0400
Received: from il.qumranet.com ([82.166.9.18])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@qumranet.com>) id 1IJER3-0001IT-4O
	for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:16:45 -0400
Message-ID: <46BB7625.2050900@qumranet.com>
Date: Thu, 09 Aug 2007 23:16:37 +0300
From: Avi Kivity <avi@qumranet.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command
	line options from qcow2 images
References: <59abf66e0708081124g14901b01i841b70d17ae1e097@mail.gmail.com>	<59abf66e0708081252of2948d7we85c9084bad245d4@mail.gmail.com>
	<20070808202428.GA25050@redhat.com>
	<46BB2A99.3030609@codemonkey.ws>
In-Reply-To: <46BB2A99.3030609@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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= <t4m5yn@gmail.com>, qemu-devel@nongnu.org

Anthony Liguori wrote:
>>
>> I think it is a bad idea from a security POV to automatically extract 
>> & use command line args from  a disk image like this without the 
>> admin explicitly requesting this capability.
>> eg If I grabbed a demo disk image from a vendors' or community 
>> website I would
>> certainly not trust whatever args may happen to be embedded in the 
>> disk image
>> and thus do not want QEMU to be automatically running using them.
>>
>> I'd recommend having some command line flag to turn this capability 
>> on. For
>> example a '--args PATH-TO-DISK' flag,
>>
>>   qemu --args $HOME/fedora.qcow
>>   
>
> That's pretty nasty.  How do you specify which disk this is then?  I 
> do agree with you that allowing arbitrary command line arguments in an 
> image file is probably a bad idea.  I think the general idea of being 
> able to launch a single image is useful but I suspect this is not the 
> right way to do it.
>
> What are some people thinking would want to be stored in the file?  
> Most of the command line options are more host specific than guest 
> specific I think.  Maybe we can store a pseudo-config instead that 
> only contains a subset of parameters (and therefore, wouldn't pose a 
> security risk)? 

Memory size, -hdb and -cdrom, processor count, networking setup.  The 
sort of things people push into ad-hoc scripts.

I expect this to be the low-end solution; with high end management 
applications storing configuration options in a database.