[Libguestfs] [PATCH 3/7] add_drive: Add selinuxnorelabel optional boolean.
Daniel P. Berrange
berrange at redhat.com
Thu Feb 28 16:01:22 UTC 2013
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 :|
More information about the Libguestfs
mailing list