On Mon, Aug 22, 2011 at 05:38:20PM +0200, Christoph Hellwig wrote: > I'm still totally against this. FD passing is a nice feature for sandboxing, > but the passing should be between closely cooperating programs. We'll > need a tool shipped from the qemu source tree to open and set up the > FDs, and not someone external. With that setup in place we can use > a protocol similar to the various OpenBSD privilegue separated deaemons > to also allow reopening / snapshots / etc. > > Opening fds in libvirt and passing them into qemu is exactly the wrong way, > and just cements the current horrors where libvirt duplicates parsing > of image format headers. The primary goal of this work is to allow QEMU to use a file, without giving it permission to open the file. This lets us cope with the current limitations of NFS wrt SELinux labelling. Where ordinarily we'd relabel the disk file to allow QEMU to open them, on NFS we can't do that. So we setup a SELinux policy that allows QEMU to read any NFS files that it is passed, but not actually open them. This allows secure use of QEMU with NFS, without having to solve the NFS + SELinux labelling problems, which is still a long term ongoing effort by NFS vendors. Whether or not libvirt parses image format headers, is a completely unrelated. Consider if libvirt did not parse image formats and instead required the mgmt app to pass in details of all backing files. We still have the problem of how to securely grant just one QEMU instance access to the files. This still needs the FD passing support being proposed here to cope with NFS. So the question of whether or not libvirt should be parsing image format headers is completely irrelevant to acceptability of this FD passing support. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list