Re: [Qemu-devel] live snapshot wiki updated

[Eric Blake <eblake@redhat.com>]

On 07/20/2011 11:27 AM, Blue Swirl wrote:
>> We've already told you - qemu must have a way to be passed fds which are
>> associated with names, and when a file refers to another backing file by
>> name, then qemu falls back on its fd/name mapping to use the already-passed
>> fd instead.  Which implies that someone else, either libvirt or a
>> qemu-maintained libblockformat.so, needs to have a stable interface for
>> parsing the backing file name out of an arbitrary qcow2 file, and that this
>> interface must work no matter how many other extensions are added to qcow2.
>
> 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.  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.

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?

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org