[Bug 1074097] New: RN: "systemctl stop apparmor" intentionally broken

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.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074097 http://bugzilla.opensuse.org/show_bug.cgi?id=1074097#c2 Christian Boltz <suse-beta@cboltz.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(suse-beta@cboltz. | |de) | --- Comment #2 from Christian Boltz <suse-beta@cboltz.de> --- (In reply to Stefan Knorr from comment #1)
I have reworked the entry (unfortunately quite a bit, to avoid blaming people and to avoid the blog style) -- would you be able to review my draft here? https://github.com/openSUSE/release-notes-openSUSE/pull/66
I'm happy to see you were able to rewrite it in a rant-free way :-) (not being involved in the discussions with systemd upstream probably helped ;-) Your text looks good, just a minor comment - if everything works as planned, Leap and SLE 15 will get AppArmor > 2.12 to solve some issues with Kubic. Therefore you might want to shorten + Starting with AppArmor 2.12 which is the version used in + &thisflavor; &version;, the command to just + Starting with AppArmor 2.12, the command
In addition, I have a few more questions: * I suspect this affects Tw..?
Yes. IIRC I already sent a mail to the factory ML when doing this change.
* I suspect this affects SLES 15 also..?
Right, SLE15 and Leap 15 AppArmor versions are in sync AFAIK, and therefore should have the same RN entry. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1074097 http://bugzilla.opensuse.org/show_bug.cgi?id=1074097#c4 --- Comment #4 from OBSbugzilla Bot <bwiedemann+obsbugzillabot@suse.com> --- This is an autogenerated message for OBS integration: This bug (1074097) was mentioned in https://build.opensuse.org/request/show/976384 15.4 / release-notes-openSUSE -- You are receiving this mail because: You are on the CC list for the bug.
participants (2)
-
bugzilla_noreply@novell.com
-
bugzilla_noreply@suse.com