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.