On Wed, Jul 20, 2011 at 8:47 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: > 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. How would libvirt know to do this touch up? > 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. Yes, I'm not worried about QEMU getting confused by libvirt. > 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? For backing file with original name of "/path/in/storage", QEMU could present the fd and the backin path by requesting something like "fd:12,/path/in/storage". The next file in chain "/path2/file" would be "fd:12,fd:34,/path2/file". Or if possible, -fd 12 -backing /path/in/storage with spaces and funny characters escaped etc. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list