We’ve identified an issue in Solus where a particular version of the apparmor package has a bug where it doesn’t load apparmor profiles for snap applications due to a simple typo-like bug prevented the code from working. Another version of the package removed the feature altogether and moved to apparmor-lsm-hooks.
Can you please confirm that you still experience this issue after updating all the packages on your system and rebooting. If that happens then please open a terminal and run:
I looked into aa-lsm-hooks over here. I ran the commands aa-lsm-hooks-compile and aa-lsm-hooks-load, and now the Simplenote snap starts even after reboot (test twice)!
I don’t really know how this works (if you have time, could you explain?), but I’m happy it does
Thanks!
EDIT: btw, the strace command doesn’t work when I tried; it just outputs
strace: Can't stat 'aa-lsm-hook': No such file or directory
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.
I’m having problem with Spotify again, does something happen in the new version?
snap version
snap 2.33.1-1.29
snapd 2.33.1-1.29
series 16
opensuse-tumbleweed 20180820
kernel 4.18.0-1-default
sudo strace -ff aa-lsm-hook
strace: Can’t stat ‘aa-lsm-hook’: No such file or directory
apparmor-lsm-hooks
If ‘apparmor-lsm-hooks’ is not a typo you can use command-not-found to lookup the package that contains it, like this:
cnf apparmor-lsm-hooks
sudo systemctl enable --now snapd.apparmor.serivce
Failed to enable unit: Unit file snapd.apparmor.serivce.service does not exist.
“~$ spotify
cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied”
I will update tumbleweed to 2.35 tomorrow. This contains a fix for the readlinkat issue you are experiencing. Sorry about the delay, I broke my tumbleweed installation recently.
I’m reworking packaging (I’m running opensuse TW daily actually, to ensure that it’s all good) but the package is not ready yet. I will try to push a test package this week, likely today as an early preview.
As a small update on this effort. I’ve been re-working the packaging on the snapd package and the first stage was successful (I have a working “go build” setup that I can use that applies the right policy). I need to spend some time on updating the packaging of snapd to use both of those but the effort is slowly progressing.