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!.html
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: