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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list