On 07/21/11 10:36, Kevin Wolf wrote: > Am 21.07.2011 10:07, schrieb Jes Sorensen: >> Rather than trying to do this by mangling files on the disk, I would >> suggest we allow registering a call-back open function, which calls back >> into libvirt and requests it to open a given file. It can then do all >> it's security foo to decide whether or not to allow the file to be open. >> >> This is relatively clean and avoids the mess of relying on outside >> processes messing about in the images. > > You forget that libvirt parses images exactly to decide whether to allow > accesses or not, so they would still do it. Which shouldn't be a big > problem anyway as long as the libvirt implementation is compliant to the > image format specification (even though it's not nice, of course). As I just responded to Daniel, this doesn't make sense. If libvirt wants to guard against a compromised QEMU, it cannot rely on things written into image files headers by QEMU. If we trust contents of image files, there is no reason not to grant QEMU full access to files on NFS either, as we have effectively already granted that by trusting the image file content. In other words, if the goal is to make this secure, lets make it secure, otherwise, lets stop pretending. > I just wonder why libvirt doesn't trust qemu enough that it can open() > what it wants, but at the same time relies for this check on information > in image files which this very same qemu can modify. Probably for the same reason few QEMU developers trust libvirt.... Jes -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list