Re: [libvirt] [Qemu-devel] live snapshot wiki updated

[Jes Sorensen <Jes Sorensen redhat com>]

On 07/20/11 19:47, Eric Blake wrote:
> On 07/20/2011 11:27 AM, Blue Swirl wrote:
>> I'd avoid any name based access in this case. If QEMU has write access
>> to main file, it could forge the backing file name in main file to
>> point to for example /etc/shadow and then request libvirt to perform
>> the opening.
> 
> Won't work.  Well, it might work within the context of a single qemu
> process.  But when that process ends, then libvirt would have to touch
> up the qcow2 headers of that file to replace the /etc/shadow name with
> the real backing file name, otherwise, the next time you restart
> qemu-img or a new qemu guest using the same image, the information has
> been lost, since the fd has been closed in the meantime.
> 
> We really _do_ need a way to give qemu both an fd and the name of the
> file that the fd is tied to.  On Linux, qemu could use /proc/self/fd to
> reconstruct the name from fd, but that's not portable to other OS.  And
> we've already discussed how in the libvirt model, that libvirt is deemed
> more secure than qemu.

I am sorry, but this is where your assertion fails completely. QEMU
cannot trust libvirt being able to parse it's image files correctly, so
this is a total no-go.

> Therefore, I think it is reasonable for qemu to
> make the assumptions that if it exposes a monitor command where the
> supervisor (libvirt or otherwise) can pass in both an fd and a file
> name, that either the supervisor is passing in correct information, or
> that the bug is in the supervisor and not in qemu if the supervisor
> passes in wrong information and things blow up.

Sorry but this is not a reasonable situation given how you want to abuse it.

> And the snapshot_blkdev monitor command is a case where qemu needs to
> create a new qcow2 image on the fly, while referencing the name of an
> existing file.  What backing name do you put in the new qcow2 file
> unless you already have a name association for all fds already open for
> the existing backing file?

It is more than that, the problem is also there when you try to open an
image that has a backing file in an selinux environment where qemu isn't
allowed to open the backing file.

This problem needs a proper solution which does not involve libvirt
messing about in binary files where it has no business of being.

Jes