/etc/init.d/apparmor stop cannot and should not invoke aa-teardown. Such a stop mechanism was the source of many problems and the reason stop was switch to a no-opin /etc/init.d/apparmor and teardown was added.
Unfortunately systemd implements restart as stop followed by start. This a very poor fit for apparmor as once the security state is torn down you have to restart all services or in some cases the entire system. Admittedly the current situation is less than ideal, there are WI scheduled to help better address this but atm the stop behavior is deliberate as on a whole it causes less problems than using teardown. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1878333 Title: AppArmor cache entries not removed when profile is deleted Status in apparmor package in Ubuntu: Confirmed Bug description: This concerns apparmor 2.13.3-7ubuntu5 in Ubuntu focal. If I delete a profile from /etc/apparmor.d/, reboot the system, and then look in /var/cache/apparmor/XXXXXXXX.0/, I still see a file for the compiled form of the profile. The same occurs if the profile is "deleted" by other means, such as symlinking it from /etc/apparmor.d/disable/. This behavior caused me some consternation as I was developing an alternate profile for a program that already had one, and I continued to see old behavior even though I had removed the old profile. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1878333/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
