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

[Jes Sorensen]

On 07/21/11 15:07, Markus Armbruster wrote:
> Jes Sorensen <Jes.Sorensen at redhat.com> writes:
>> Right, we're stuck with the two horros of NFS and selinux, so we need
>> something that gets around the problem. In a sane world we would simply
>> say 'no NFS, no selinux', but as you say that will never happen.
>>
>> My suggestion of a callback mechanism where libvirt registers the
>> callback with QEMU for open() calls, allowing libvirt to perform the
>> open and return the open file descriptor would get around this problem.
> 
> No go, I'm afraid.
> 
> The problem at hand is how to confine the untrusted QEMU process so it
> can access exactly the resources the guest configuration specifies, no
> more, no less.
> 
> When guest configuration says "use image A", it really means "file A
> plus certain other resources that are required to use it".  For obvious
> usability reasons, we don't require spelling out "certain other" if we
> can safely get the information from A.
> 
> Example: file foo.qcow2 requires its backing file file foo.img.
> 
> Obviously, the code to get information from A must be trusted.
> Therefore, it can't run in the untrusted QEMU process.
> 
> Example: the proposed callback mechanism.
> 
>     Guest configuration says "use image foo.qcow2".  Libvirt (or
>     whatever management layer) arranges that the QEMU process can use
>     file foo.qcow2.
> 
>     The QEMU process then uses the callback to gain access to the
>     backing file.  Nothing stops it to ask for whatever file it wants.
>     How can libvirt decide whether the file is one of the resources the
>     guest configuration specifies?
> 
> The only way I can see around having libvirt read resource information
> from images (preferably via a suitable library provided by QEMU) is to
> require the administrator to spell out the resouce information.
> Administrators generally don't fancy spelling out things the computer
> already knows.

As I pointed out in other parts of the discussion, libvirt must carry a
complete list of authorized files/devices that a guest is allowed to
access. There is no way around this anyway, and since this is the case,
it's not a showstopper for using the callback mechanism.

Cheers,
Jes