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@xxxxxxxxxxxxxxxxxx>
>> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list