Hey. I ran the code from master so I may have seen a newer version.
The way this works is that Ikey has shifted the responsibility of loading apparmor profiles from the apparmor.service (a systemd unit that runs a bunch of shell scripts) into the aa-lsm-hooks project, which is written in C and does exactly what the old code did but with more tight code and error handling.
As to what happens when either of those things run. Apparmor profiles are text files that just sit on your disk. Old-school classic packages have their apparmor profiles (very few do) in
/etc/apparmor.d, all of the snap applications have their profiles stored in
/var/lib/snapd/apparmor/profiles. The thing is, those profiles do nothing unless they are compiled and loaded into the kernel. This is done by snapd when you install a snap but the kernel doesn’t remember that across reboots. When a system reboots something needs to take all of the existing profiles, compile and load them.
This is exactly what the
aa-lsm-hooks does. Since it’s a solus-specific invention we don’t do regression testing against it. Ideally it would be proposed upstream to the apparmor project but I don’t know if the Solus project is interested that just now.
In either case it is a solus-specific bug that the profiles somehow are not loaded across reboots. We plan to ship our own loader in case this problem persists. We wrote our own loader for another case (specifically for openSUSE Tumbleweed) but we need cooperation from Ikey or other people that can upload the snapd package to achieve this.