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 did not want to modify the stock file. Specifically (assuming the profile is "usr.bin.foo"), I created usr.bin.foo.new, and symlinked usr.bin.foo from disable/. It appears to me that aa-remove-unknown (or something like it) should be invoked on startup. The cache is supposed to be an implementation detail (so that the system doesn't spend much time compiling the profiles every time they are loaded), but in this case, it is behaving as a sort of opaque "shadow config" outside of /etc, which is very bad. I can understand that if I edit a file under /etc, the change may not take effect as soon as I save it. Sometimes I have to send a SIGHUP, sometimes I have to restart the daemon, etc. But if I reboot the system, then I think it is reasonable to assume that the entire system config is reloaded (or behaves as if it were reloaded) from /etc. The cache should be properly updated by the system in that situation---it should not require additional action by the user. -- 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: AppArmor cache entries not removed when profile is deleted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1878333/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
