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? ;-)