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(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org