containers
New apparmor rules don't trigger a new profile unless upstream version is changed
When the apparmor template is changed, like was done recently to fix issue #1898 via PR #2004, the upstream version was not chagned, which means the default apparmor profile name remained the same.
This means that even with a new build, users launching new containers will still be affected by the bug as long as the previous apparmor profile is still loaded. That's because when a new container is launched, and no apparmor profile specified, it will check if the default profile is already loaded into the kernel before loading it again. But in this case the profile content is different, as it has fixes, but the version didn't change, so it's not loaded. In other words, the name of the default profile should have been changed, or another logic needs to be in place to accommodate for cases when the embedded apparmor profile needs to be reloaded.
For downstream distributions, they could patch apparmor.go and include the full package version in there, so instead of being something like containers-default-0.57.4, it would become something like 0.57.4+ds1-2ubuntu1, which is the full package version. This would make the new, fixed, apparmor profile be loaded, instead of reusing the old one which does not have the fix.
This is not needed for every single version bump, but only when the profile has changed. So maybe another mechanism should be considered. Was it ever considered to always load the profile, and that had some negative impact, like performance? Or fear that it could negatively impact already existing containers?
