On Thu, Feb 28, 2013 at 03:52:32PM +0000, Matthew Booth wrote:
On Thu, 2013-02-28 at 15:49 +0000, Daniel P. Berrange wrote:
On Thu, Feb 28, 2013 at 03:01:20PM +0000, Matthew Booth wrote:
Secondly, by relabelling disk images we're potentially making them temporarily unavailable to other processes, which is something we weren't doing before. It's possible there may be no way round this, but if so we ought to highlight it as a major gotcha. Is there any way we can give a file 2 different SELinux contexts? If there were, we could leave the original untouched and only allow our ephemeral process to access the second one. A hard link doesn't allow this, btw. A copy is almost certainly infeasible in the general case, but if the FS allows reflink it might fly. Thoughts?
There will never be any way to give one file multiple SELinux labels. It is explicitly rejected as a concept by security people.
What I describe here though is explicitly about *not* having to make libguestfs relabel other disk images. The point is to define a policy such that libguestfs can access the other VMs' disks without any relabelling needing doing to them.
Any relabelling would only be needing on any qcow2 snapshot that libguestfs has above the original disks.
I wasn't talking about whether libguestfs or libvirt does the relabelling, I was talking about the problems of any relabelling happening at all to the input file.
Sorry, what do you mean by "input file" here ? What files in particular are you worried about 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 :|