[libvirt] Printing runtime DAC seclabel in the XML

Martin Kletzander mkletzan at redhat.com
Thu Apr 21 10:08:23 UTC 2016


On Wed, Apr 20, 2016 at 07:57:05PM -0400, Cole Robinson wrote:
>I'm looking in the code to see why runtime VM dac seclabel values aren't
>printed in the active XML. They are filled in, but the domain XML formatter
>explicitly skips it:
>
>    /* To avoid backward compatibility issues, suppress DAC and 'none' labels
>     * that are automatically generated.
>     */
>    if ((STREQ_NULLABLE(def->model, "dac") ||
>         STREQ_NULLABLE(def->model, "none")) && def->implicit)
>        return;
>
>The relevant bit is from here:
>
>commit 990e46c4542349f838e001d30638872576c389e9
>Author: Marcelo Cerri <mhcerri at linux.vnet.ibm.com>
>Date:   Fri Aug 31 13:40:41 2012 +0200
>
>    conf: Avoid formatting auto-generated DAC labels
>
>And I think comment elsewhere in domain_conf.c explains what that's all about:
>
>    /* libvirt versions prior to 0.10.0 support just a single seclabel element
>     * in guest's XML and model attribute can be suppressed if type is none or
>     * type is dynamic, baselabel is not defined and INACTIVE flag is set.
>     *
>     * To avoid compatibility issues, for this specific case the first model
>     * defined in host's capabilities is used as model for the seclabel.
>     */
>
>Just dropping the the model == "dac" check above seems to accomplish what I'm
>after, but it's not strictly back compatible. That said, libvirt has supported

I think this has nothing to do with backward compatibility, but forward
compatibility (which we care about for "some" time).

What are you trying to achieve?  It works for me, the default seclabel
is not exposed, but if I change it, it is dumped for running, shut-off
or whatever domain there is.

>multiple seclabels for a loooong time now, so I wonder do we even care? Do we

Probably migration to older versions, but I'm not sure that there's that
many people who care about it.  And it won't work because of other
things too -- I think it's just not supported use-case anyway.

>have a target for how far back we try to maintain XML compat? Or does anyone
>else have other ideas?
>

Back-compat has now something like a 10½ years now and I think it will
reach around 15 in next 5 years...

>(ccing jiri and michal who have had patches in this area)
>
>Thanks,
>Cole
>
>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160421/f8716443/attachment-0001.sig>


More information about the libvir-list mailing list