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 :|