[libvirt] [PATCH] virSecurityLabelDefParseXML: Don't parse label on model='none'

Daniel P. Berrange berrange at redhat.com
Mon Nov 11 10:51:52 UTC 2013


On Mon, Nov 11, 2013 at 10:49:44AM +0100, Michal Privoznik wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1027096
> 
> If there's the following snippet in the domain XML, the domain will be
> lost upon the daemon restart (if the domain is started prior restart):
> 
>     <seclabel type='dynamic' relabel='yes'/>
> 
> The problem is, the 'label', 'imagelabel' and 'baselabel' are parsed
> whenever the VIR_DOMAIN_XML_INACTIVE is *not* present or the label is
> static. The latter is not our case, obviously. So, when libvirtd starts
> up, it finds domain state xml and parse it. During parsing, many XML
> flags are enabled but VIR_DOMAIN_XML_INACTIVE. Hence, our parser tries
> to extract 'label', 'imagelabel' and 'baselabel' from the XML which
> fails for model='none'. Err, this model - even though not specified in
> XML - can be taken from qemu wide config file: /etc/libvirtd/qemu.conf.
>
> However, in order to know we are dealing with model='none' the code in
> question must be moved forward a bit. Then a new check must be
> introduced. This is what the first two chunks are doing.

I'm not sure I understand your explanation here, but this label:

 <seclabel type='dynamic' relabel='yes'/>

is not model='none'. This is intended to be associated with whatever
model is currently activated. So it may be model=none or model=selinux
or model=apparmour - none of this should matter for the parser though.
When the guest is actually started an explicit model='XXXX' should be
added to the XML - eg the live state XML should always have a model
set.

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 libvir-list mailing list