Re: [libvirt] Printing runtime DAC seclabel in the XML

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(a)linux.vnet.ibm.com&gt; >> 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)