Am 21.07.2011 10:07, schrieb Jes Sorensen: > On 07/20/11 21:51, Blue Swirl wrote: >>> 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. > > Rather than trying to do this by mangling files on the disk, I would > suggest we allow registering a call-back open function, which calls back > into libvirt and requests it to open a given file. It can then do all > it's security foo to decide whether or not to allow the file to be open. > > This is relatively clean and avoids the mess of relying on outside > processes messing about in the images. You forget that libvirt parses images exactly to decide whether to allow accesses or not, so they would still do it. Which shouldn't be a big problem anyway as long as the libvirt implementation is compliant to the image format specification (even though it's not nice, of course). I just wonder why libvirt doesn't trust qemu enough that it can open() what it wants, but at the same time relies for this check on information in image files which this very same qemu can modify. Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list