[libvirt] Printing runtime DAC seclabel in the XML

[Cole Robinson]

On 04/21/2016 06:08 AM, Martin Kletzander wrote:
> 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).
> 

That's not my reading of the patch + thread. I think it was that new libvirt
starting printing two <seclabel> blocks for active XML. If you then do a
managedsave, downgrade libvirt, and attempt a restore (or live migration to an
older version), old libvirt errors when it sees 2 <seclabel> blocks. So back
compat here to me meant 'generate XML that old libvirt will accept'

> 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.
> 

the issue: start a VM with no explicit seclabel config, dump the running XML,
you'll see something like this:

  <seclabel type='dynamic' model='selinux' relabel='yes'>
    <label>unconfined_u:unconfined_r:svirt_t:s0:c325,c747</label>
    <imagelabel>unconfined_u:object_r:svirt_image_t:s0:c325,c747</imagelabel>
  </seclabel>

but no <seclabel> block for DAC labels, which seems inconsistent

>> 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...
> 

I should have been more explicit. Certainly for things like XML input we aim
to maintain back compat to the beginning, which is why tools like virt-install
can reliably work across versions.

In this case though I meant XML output back compat/migration back compat: do
we still think it's a worthy goal to maintain XML output compat with libvirt
<= 0.10.0 ? (and if so, I imagine there's a better place to handle this...
somewhere migration specific? but I'm not really familiar with the latest
infrastructure for that)

- Cole