qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read	command line options from qcow2 images
Date: Thu, 09 Aug 2007 19:48:14 -0500	[thread overview]
Message-ID: <46BBB5CE.9090705@codemonkey.ws> (raw)
In-Reply-To: <1186692923.20963.52.camel@wombat.dlib.indiana.edu>

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
>
>
>
>
>
>
>   

  reply	other threads:[~2007-08-10  0:48 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <59abf66e0708081124g14901b01i841b70d17ae1e097@mail.gmail.com>
2007-08-08 19:52 ` [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images Jorge Lucángeli Obes
2007-08-08 20:24   ` Daniel P. Berrange
2007-08-09 14:54     ` Anthony Liguori
2007-08-09 15:07       ` Daniel P. Berrange
2007-08-09 20:16       ` Avi Kivity
2007-08-09 20:25         ` Anthony Liguori
2007-08-09 20:30           ` Avi Kivity
2007-08-09 20:32             ` Anthony Liguori
2007-08-09 20:39               ` Avi Kivity
2007-08-09 20:44               ` Brian Wheeler
2007-08-09 20:49                 ` Anthony Liguori
2007-08-10  3:51                 ` dmc
2007-08-10 13:26                   ` Carlos A. M. dos Santos
2007-08-09 20:55         ` Brian Wheeler
2007-08-10  0:48           ` Anthony Liguori [this message]
2007-08-11 17:11   ` andrzej zaborowski
2007-08-11 18:06     ` Philip Boulain
2007-08-11 19:08       ` Christian Brunschen
2007-08-11 19:53         ` Anthony Liguori
2007-08-11 19:52       ` Anthony Liguori
2007-08-11 21:28         ` Philip Boulain
2007-08-11 23:17           ` Anthony Liguori
2007-08-13  5:34             ` Jorge Lucángeli Obes
2007-08-13 15:15               ` [kvm-devel] " Anthony Liguori
2007-08-11 19:49     ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46BBB5CE.9090705@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).