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
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
