We plan to ship our own loader in case this problem persists. In either case it is a solus-specific bug that the profiles somehow are not loaded across reboots. Ideally it would be proposed upstream to the apparmor project but I don’t know if the Solus project is interested that just now. Since it’s a solus-specific invention we don’t do regression testing against it. This is exactly what the aa-lsm-hooks does. When a system reboots something needs to take all of the existing profiles, compile and load them.
This is done by snapd when you install a snap but the kernel doesn’t remember that across reboots. The thing is, those profiles do nothing unless they are compiled and loaded into the kernel. 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.
Apparmor profiles are text files that just sit on your disk. The way this works is that Ikey has shifted the responsibility of loading apparmor profiles from the rvice (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.Īs to what happens when either of those things run.
I ran the code from master so I may have seen a newer version.
0 kommentar(er)
