From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IJEZj-0005HV-Nc for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:25:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IJEZj-0005HD-6L for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:25:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IJEZj-0005HA-0l for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:25:43 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IJEZi-0003a6-No for qemu-devel@nongnu.org; Thu, 09 Aug 2007 16:25:42 -0400 Received: by an-out-0708.google.com with SMTP id d11so164923and for ; Thu, 09 Aug 2007 13:25:42 -0700 (PDT) Message-ID: <46BB7842.1030101@codemonkey.ws> Date: Thu, 09 Aug 2007 15:25:38 -0500 From: Anthony Liguori 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> <46BB7625.2050900@qumranet.com> In-Reply-To: <46BB7625.2050900@qumranet.com> 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: Avi Kivity Cc: =?ISO-8859-1?Q?Jorge_Luc=E1ngeli_Obes?= , qemu-devel@nongnu.org Avi Kivity wrote: > 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. If you're looking for a low-end solution, another possibility would be having a "new" file format which consisted of: #!/path/to/qemu [ ...] And then make the appropriate changes to QEMU such that it can skip the first line in a disk image file. This has a few nice side effects. The disk image is directly executable and it makes it very clear to the user that they have to trust the disk image. The other nice thing is that it would work with file formats other than qcow2. Regards, Anthony Liguori