That's why I hedged on having something like "apparmor unload". What
you're saying explains why "restart" and "reload" are distinct actions
(I'd never been clear on this), so having a new action that is "like
'stop' but actually does stop apparmor, even though that is not usually
what you want" mak
/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 fi
A related issue: "/etc/init.d/apparmor stop" should invoke aa-
teardown(8). Depending on the semantics of the apparmor "service," this
could also be "/etc/init.d/apparmor unload" or the like. I was surprised
to find that "apparmor stop" was not actually unloading the profiles, as
I had assumed.
>F
Thanks. I am in complete agreement.
I don't need (or even want) AppArmor to automagically update the kernel
state right after changing something under /etc/apparmor.d/, because
having to do a SIGHUP/restart/etc. is already normal practice. But I do
expect that a reboot/reload will take care of tha
Daniel,
Right the profile should be removed on reboot, or service restart,
having stale cache files loaded is a huge problem.
It is the auto-cleanup of old cache files when a profile is manually
deleted/renamed that is a wishlist item.
With this clarification I am moving this from wishlist back
Hello John,
I did not take any specific action to unload a profile from the kernel.
Instead, I rebooted the system, under the assumption that this would
wipe the slate clean, with everything reloading cleanly from
/etc/apparmor.d/.
The new profile I developed was under a new filename, because I d
Daniel,
Currently it is expected that manually deleting a profile also requires manual
profile removal from the kernel, using an of
- aa-remove-unknown
- apparmor_parser -R
- sudo bash -c "echo -n '' >
/sys/kernel/security/apparmor/.remove"
However this does indeed currently leave behind the c
** Changed in: apparmor (Ubuntu)
Status: New => Confirmed
** Changed in: apparmor (Ubuntu)
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1878333
Title:
A
