[libvirt] [Qemu-devel] live snapshot wiki updated
Jes Sorensen
Jes.Sorensen at redhat.com
Thu Jul 21 14:15:36 UTC 2011
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
More information about the libvir-list
mailing list