Comment 0 for bug 853330

I've only just thought of this issue, and have not investigated further. There may be a security issue in enabling qcow images that could be exploited like this:

 * user creates an image with 'qemu-img create -f qcow2 -b <FILE> mytest.img' . Here, FILE could be anything thing (/etc/shadow, /var/lib/libvirt/qemu/isntance-0000030/disk.local).
 * user uploads images: cloud-publish-image x86_64 mytest.img mybucket
 * user runs instance

Things that may make this less severe:
 * i believe in ubuntu that the user libvirt-qemu user is used to run kvm, so that the file access might be limited to what that user can access.
 * in ubuntu apparmor profiles for libvirt *may* improve this, although I don't know that they were written to protect against this.
 * the instance wont' actually boot. (However, I think it may be possible using block-device-mapping to attach a bootable snapshot to this instance that *would* boot, and then access the root disk that way).

I believe this could be fixed by simply refusing to run a qcow2 formated image (or any disk image) whose original image contained a backing store reference . Ie, if 'qemu-img info <disk>' showed a 'backing file:' entry.