Re: [Libguestfs] [PATCH 4/7] launch: libvirt: Allow the SELinux label to be set on qcow2 overlay files.
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