http://bugzilla.opensuse.org/show_bug.cgi?id=1074097 Bug ID: 1074097 Summary: RN: "systemctl stop apparmor" intentionally broken Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Release Notes Assignee: sknorr@suse.com Reporter: suse-beta@cboltz.de QA Contact: lnussel@suse.com Found By: --- Blocker: --- Please add this information about AppArmor to the Leap 15 release notes (copy&paste from https://blog.cboltz.de/archives/77-AppArmor-2.12-The-Grinch-is-confined!.htm... and assuming that Leap 15 will pick up AppArmor 2.12 or newer) --- One important change in the [AppArmor 2.12] packages is that I intentionally broke "systemctl stop apparmor". The reason for this is "systemctl restart apparmor" - systemd maps this to stop, followed by start. This resulted in unloading all AppArmor profiles by the "stop" part and, even if they get loaded again a second later, running processes will stay unconfined unless you restart them. The systemd developers were unwilling to implement the proposed ExecRestart= option for unit files, therefore breaking "stop" is the best thing I can do. (See boo#996520 and boo#853019 for more details.) "systemctl reload apparmor" will continue to work and is still the recommended way to reload the AppArmor profiles, but accidently typing "restart" instead of "reload" can easily happen. Therefore I chose to break "stop" - that's annoying, but more secure than accidently removing the AppArmor confinement from running processes. If you really want to unload all AppArmor profiles, you can use the new "aa-teardown" command which does what "systemctl stop apparmor" did before - but who would do that? ;-) -- You are receiving this mail because: You are on the CC list for the bug.