On 07/20/11 12:28, Daniel P. Berrange wrote: > On Wed, Jul 20, 2011 at 12:15:02PM +0200, Nicolas Sebrecht wrote: >> 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. Well that part goes both ways. By applying this model you are going to make it a hard requirement for libvirt to be upgraded with QEMU even for smaller updates. >>> 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. Of course it is: hotplug Jes -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list