On 07/21/11 15:07, Markus Armbruster wrote: > Jes Sorensen <Jes.Sorensen@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list