[apparmor] Asking for best practice on upgrading in regard to named profiles

[Christian Ehrhardt]

Hi,
today I saw an interesting patch to libvirt [1] (thanks Jim) that made
me think more about proper migration through those changes.

TL;DR:
- profile A with binary-path
- profile B referencing peer A by binary-path
- profile A gets updated to now have name + binary-path
- profile A gets loaded by name now
- will profile B no more "find" it's reference in the peer statement
as it "only" references the binary-path?

Details:
So to me [1] seems safe and it tells me that "if you are unsure what
your peer is using" then the way to go is to duplicate the rules
keeping the binary-path and adding the named reference in addition.
Some proliferation, but otherwise safe in terms of package upgrades.

But then there also is [2]. The change here first looks similar with:
- the first hunk referencing name+binary-path via the {profile_name}
  (I guess that is what it does)
- The second hunk again doing the proliferation to list path & name

Feel free to correct me above if my assumptions were incorrect already.
But what I wondered about mostly was the hint that using [2] might
need some coordination with apparmor (e.g. on package dependencies) to
quote "... since the dnsmasq profile currently has
'peer=/usr/sbin/libvirtd'"

Now I wonder, if a profile has name and binary-path like in [2]
    profile libvirtd /usr/sbin/libvirtd
and another profile was referencing it with the old path, in this case
"/usr/sbin/libvirtd", but the new profile is now loaded "by name" will
the profile of dnsmasq no more "recognize" it's peer.

Sorry for my lack of knowledge on that detail, but after a discussion
with Jamie this morning we thought it is better to have that
clarification upstream.

[1]: https://www.redhat.com/archives/libvir-list/2019-January/msg00388.html
[2]: https://www.redhat.com/archives/libvir-list/2019-January/msg00389.html

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd