[Libguestfs] [PATCH 4/7] launch: libvirt: Allow the SELinux label to be set on qcow2 overlay files.
Matthew Booth
mbooth at redhat.com
Thu Feb 28 15:18:22 UTC 2013
On Thu, 2013-02-28 at 14:41 +0000, Daniel P. Berrange wrote:
> On Thu, Feb 28, 2013 at 02:31:23PM +0000, Richard W.M. Jones wrote:
> > On Thu, Feb 28, 2013 at 02:24:30PM +0000, Richard W.M. Jones wrote:
> > > On Thu, Feb 28, 2013 at 02:14:42PM +0000, Matthew Booth wrote:
> > > > Relabelling the appliance could get complicated wrt multiple
> > > > appliances running simultaneously.
> > >
> > > Right -- I suspect this is buggy actually, but it's quite hard to test
> > > it since I need to run up lots of guests and run virt-df in parallel
> > > on them. Also we put <shareable/> on the appliance disk, and I'm not
> > > sure what libvirt does in that case.
> >
> > I spun up a few libvirt guests and surprisingly this all seems to
> > work. I have no idea why :-) I agree with you that it shouldn't work
> > because the labels should get stomped on by the different connections,
> > but it seems libvirt is being cleverer somehow.
>
> For any disk with <sharable/> set, libvirt ignores the VM MCS level
> and labels the disk with a simple svirt_image_t label which allows
> *every* VM running on the host to have read-write access to the
> disk.
>
> You can't share disks between VMs, if they have MCS levels attached,
> unless the VMs all have the same MCS level themselves.
Presumably, therefore, a <shareable/> disk is only guaranteed to be
shareable between processes with the same SELinux context. I'm guessing
that <seclabel/> defaults to svirt_t, but is configurable? If I'm right
and you set it to something else, which would also require custom
policy, this would fail. Presumably the behaviour of <shareable/> must
also have some prior knowledge of the behaviour of the policy in order
to be able to create a label which will work. How does it do this?
I think the only way you can guarantee this to work is to create an
appliance per user/selinux label instead of just per user. With per-VM
categories this would create a lot of appliances, though.
Matt
More information about the Libguestfs
mailing list