On Thu, Aug 09, 2007 at 09:54:17AM -0500, Anthony Liguori wrote: > Daniel P. Berrange wrote: > >On Wed, Aug 08, 2007 at 04:52:58PM -0300, Jorge Luc?ngeli Obes wrote: > > > >>This patch makes QEMU check for command line options stored in qcow2 > >>images. > >> > > > >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
Well that's the same problem you have with the current patch - it just assumes you have a single disk & its going to be hda. > 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)? Yeah that's a much more open ended & interesting problem to address. I personally wouldn't store command line arguments in the image at all. I think we'd be better off providing a generic metadata description of the capabilities / requirements of the guest OS/kernel inside the image. So any virtualization platform could read the metadata, determine whether the guest is supported & then boot it with appropriate commands. Once you have a good metadata description, there's many options for how you distribute it - in the qcow image, or in tar.gz containing the image, the metdata & any other relevant bits. We've been trying to prototype a sample metdata description & a virt-image tool for launching an image based on its metadata using libvirt. http://people.redhat.com/dlutter/virt-image/ The same metadata could be used to build a qemu command line directly for the non-libvirt usage cases. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
