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

Jes Sorensen <Jes.Sorensen(a)redhat.com&gt; 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.