[libvirt] [Qemu-devel] live snapshot wiki updated

[Anthony Liguori]

On 07/19/2011 09:30 AM, Jes Sorensen wrote:
> On 07/19/11 16:24, Eric Blake wrote:
>> [adding the libvir-list]
>> On 07/19/2011 08:09 AM, Jes Sorensen wrote:
>>> Urgh, libvirt parsing image files is really unfortunate, it really
>>> doesn't give me warm fuzzy feelings :( libvirt really should not know
>>> about internals of image formats.
>>
>> But even if you add new features to qemu to avoid needing this in the
>> future, it doesn't change the past - libvirt will always have to know
>> how to parse image files understood by older qemu, and so as long as
>> libvirt already knows how to do that parsing, we might as well take
>> advantage of it.
>
> What has been done here in the past is plain wrong. Continuing to do it
> isn't the right thing to do here.
>
>> Besides, I feel that having a well-documented file format, so that
>> independent applications can both parse the same file with the same
>> semantics by obeying the file format specification, is a good design goal.
>
> We all know that documentation is rarely uptodate, new features may not
> get added and libvirt will never be able to keep up. The driver for a
> file format belongs in QEMU and nowhere else.
>
>
>>>> It would be nice if libvirt had a way to pass fds for every disk and
>>>> backing file up front; then, SELinux can work around the lack of NFS
>>>> per-file labelling by blocking open() in qemu.  In fact, this has
>>>> already been proposed:
>>>
>>> A cleaner solution seems to have libvirt provide a call-back allowing
>>> QEMU to call out and have libvirt open a file descriptor instead. This
>>> way libvirt can validate it and open it for QEMU and pass it back.
>>
>> Yes, that could probably be made to work with libvirt.
>
> I am a little frustrated this approach wasn't taken up front instead of
> the evil hack of having libvirt attempt to parse image files.
>
>>> If we cannot do something like this, I would prefer to have backing
>>> files on NFS should simply not be supported when running in an selinux
>>> setup.
>>
>> As nice as that sentiment is, it will never fly, because it would be a
>> regression in current behavior.  The whole reason that the virt_use_nfs
>> SELinux bool exists is that some people are willing to make the partial
>> security tradeoff.  Besides, the use of sVirt via SELinux is more than
>> just open() protection - while the current virt_use_nfs bool makes NFS
>> less secure than otherwise possible, it still gives some nice guarantees
>> to the rest of the qemu process such as passthrough accesses to local
>> pci devices.
>
> Well leaving things at status quo is not making it worse, it just leaves
> an evil in place.

NFS and SELinux is a fundamental problem with SELinux and NFS.  We can 
piss and moan as much as we want about it but it's reality.  SELinux 
fundamentally requires extended attributes.  By the time NFS adds 
extended attribute support, we'll all be flying around in hover cars.

As terrible as NFS is, people use it all of the time.

It would be nice if libvirt had the ability to make better use of DAC to 
support isolation.  The fact that MAC is the only way you can do 
isolation between guests is pretty unfortunate.  If I could assign 
specific UIDs to a guest and use that to enforce isolation, it would go 
a long ways to solving this problem.

Regards,

Anthony Liguori