On Wed, Jul 20, 2011 at 4:46 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > On 07/20/2011 07:25 AM, Jes Sorensen wrote: >>> >>> I think if libvirt wants qemu to use an fd instead of a file name, it >>> shouldn't pass a file name but an fd in the first place. Which means >>> that the two that we need are support for an fd: protocol (patches on >>> the list, need review), and a way for libvirt to override the backing >>> file of an image. >> >> The problem is that QEMU will find backing file file names inside the >> images which it will be unable to open. How do you suggest we get around >> that? > > 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list