On Thu, Jul 21, 2011 at 10:40:48AM +0200, Jes Sorensen wrote:
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
In the case of hotplug, the hotplug monitor commands have not yet been
invoked when libvirt access the file metadata, or the drive has already
been unplugged, so there is still no concurrent access to the file by
QEMU and libvirt.
Regards,
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 :|