On Wed, Jul 20, 2011 at 12:15:02PM +0200, Nicolas Sebrecht wrote: > The 20/07/11, Daniel P. Berrange wrote: > > > To make the decision whether the filename from QEMU is valid, we have > > to parse the master image header data to see if the filename actually > > matches the backing file required by the image assigned to the guest. > > Actually, libvirt should not have to worry if the filename provided by > QEMU is valid. I think it should trust QEMU. If QEMU doesn't provide > information others can trust; it should be fixed at QEMU side. The security goal of libvirt is to protect the host from a compromised QEMU, therefore QEMU is, by definition, untrusted. > > We're not fighting over the internals of metadata. We just need to know > > ahead of launching QEMU, what backing files an image has & what format > > they are in. We do that by reading at the metadata headers of the disk > > images. We never attempt to write to the disk images. Either someone > > provides a library todo that, or we write the probing code for each > > file format in libvirt. Currently we have the latter. > > This is what I would call "fighting with QEMU internals". How do you > prevent from concurrency access and modifications? Ideally speacking > libvirt should be able to co-exist with foreign implementations, all > requesting QEMU. QEMU is *not* yet running at the time libvirt reads the file metadata. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list