From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IJIg2-0004LX-Ai for qemu-devel@nongnu.org; Thu, 09 Aug 2007 20:48:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IJIg1-0004KA-Nx for qemu-devel@nongnu.org; Thu, 09 Aug 2007 20:48:29 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IJIg1-0004Jt-G4 for qemu-devel@nongnu.org; Thu, 09 Aug 2007 20:48:29 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IJIg1-0000Sq-3o for qemu-devel@nongnu.org; Thu, 09 Aug 2007 20:48:29 -0400 Received: by wx-out-0506.google.com with SMTP id h31so476899wxd for ; Thu, 09 Aug 2007 17:48:22 -0700 (PDT) Message-ID: <46BBB5CE.9090705@codemonkey.ws> Date: Thu, 09 Aug 2007 19:48:14 -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> <1186692923.20963.52.camel@wombat.dlib.indiana.edu> In-Reply-To: <1186692923.20963.52.camel@wombat.dlib.indiana.edu> 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: qemu-devel@nongnu.org Brian Wheeler wrote: > On Thu, 2007-08-09 at 23:16 +0300, 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. >> >> >> > > Why not just save the options to a file and have qemu parse it? That > way all of the security issues are taken care of, and it can be cross > platform (no need for a shell script and/or batch file) so it'd be > portable. > > If the format was one flag per line (as if the command line got broken > up in pairs) as in "-hdb myfile.img" being on one line and "-fda > boot.img" on another line, then its easy to edit programically as well. > > All of my shell scripts to start qemu tend to look like this: > > qemu -hda disk0.img -net nic -net user -m 512 -localtime $* > > so I can pass one-time parameters as necessary (that's the $* at the > end) by specifying args when I invoke the script. If qemu had a default > configuration file it looked for, and then you could specify one-or-more > configuration files to read in addition (later values overriding earlier > ones), then it seems like it'd work out for most if not all situations. > Yes, I agree config files are the proper solution here but that's a pretty big effort. It may be valuable to have an intermediary solution. Regards, Anthony Liguori > > Brian > > > > > > >