Page MenuHomeSolus

Snap (cgroup.procs: Permission denied)
Closed, ResolvedPublic

Description

Testing new version of snap (2.49.1) by installing some packages found this error.

$ sudo snap install snap-store
error: cannot perform the following tasks:
- Run configure hook of "snap-store" snap if present (run hook "configure": cannot open file /sys/fs/cgroup/freezer/snap.snap-store/cgroup.procs: Permission denied)

$ sudo snap install notepad-plus-plus
error: cannot perform the following tasks:
- Run configure hook of "notepad-plus-plus" snap if present (run hook "configure": cannot open file /sys/fs/cgroup/freezer/snap.notepad-plus-plus/cgroup.procs: Permission denied)

While in Boxes I have Solus Gnome with snap-store installed, before the update it was running fine, but after switching to unstable repository and updating the system, it doesn't run:

$ snap-store
cannot open /sys/fs/cgroup/devices/snap.snap-store.snap-store: Permission denied

Both give same error.

Event Timeline

algent created this task.Mar 18 2021, 7:56 PM
algent updated the task description. (Show Details)Mar 18 2021, 7:57 PM
algent updated the task description. (Show Details)Mar 18 2021, 9:45 PM
JoshStrobl triaged this task as Normal priority.Mar 19 2021, 9:54 AM
JoshStrobl edited projects, added Software; removed Lacks Project.
JoshStrobl added subscribers: DataDrake, JoshStrobl.

I was able to reproduce the issue related to freezer under 5.11.7-175.current with systemd 246.4-91.

Under 5.11.7-175 with systemd 247.4-92, it fails with a different error of failing to open / write contents in /sys/fs/cgroup/devices/ (in my testing this was affecting even already installed snaps, not just when installing), however with the AppArmor confinement patches from Ubuntu that we also ship in our kernels removed (in a local 5.11.7-176 with new systemd) , I get yet another different error, which is it failing to write maintenance.json, search result in their repo here, and failing with Run configure hook of "notepad-plus-plus" snap if present (run hook "configure": execv failed: No such file or directory)

This only seems to happen with snaps using the configure hook. I wasn't getting the error you had related to permission denied on devices until my systemd upgrade, which sounded to me like something odd at play with apparmor confinement or policies (not entirely ruling out systemd's apparmor policy loading however that landed in 246 which we've been on for a while). At the moment there wouldn't be any downsides to removing the confinement patches we have in our kernels however, as snapd with cgroups v2 does not support strict confinement (only partial), which was more-or-less the point of it. As far as I can tell, nobody else besides Ubuntu and us ship with these confinement patches and they seem to have far less issues as a result. In my research I saw countless issues related to failing to read /sys/fs/cgroup related files, such as with LXD, so might be better off just dropping it entirely, and seeing if the situation improves beyond that.

Prodding @DataDrake for his thoughts.

JoshStrobl lowered the priority of this task from Normal to Needs More Info.Mar 19 2021, 9:55 AM
JoshStrobl moved this task from Backlog to System and Configuration Fixes on the Software board.
Jacek added a subscriber: Jacek.Mar 20 2021, 12:02 AM
Harvey added a subscriber: Harvey.Mar 20 2021, 1:16 AM

One thing to note first, @joebonrichie mentioned on IRC that systemd is still being built with default-hierarchy=legacy. That might be a quick thing to tweak with before messing with the kernels.

Barring having the time to dig through Ubuntu's 400k lines of patches to 5.11 to get their updated apparmor patches: https://launchpadlibrarian.net/525732115/linux_5.11.0-11.12.diff.gz

I guess I'd say let's at least try without it for now and see what happens.

I already tried default-hierarchy=hybrid and default-hierarchy=unified unfortunately doesn't fix the issue,

$ systemd --version
systemd 246 (246)
+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -ZSTD -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 -IDN -PCRE2 default-hierarchy=unified

p.s. snap has a hello-world snap that is useful for quick testing.

It may not have fixed it, but the errors may have been more favorable? ie. Fixes one thing we can't fix and then breaks something we can.

My systemd does not build with legacy, it builds with unified. The errors I provided are from when they were set to unified. So nope, not more favorable.

Well apparmor_parser is exhibiting different issues after further testing so going to hold off with systemd update + kernel updates for now.

Is there where I manage to convince everyone to just move over to Flatpak? >.<

JoshStrobl changed the task status from Open to In Progress.Mar 22 2021, 1:18 PM
JoshStrobl claimed this task.
JoshStrobl raised the priority of this task from Needs More Info to High.

Marking as high and in progress. Investigating moving us to apparmor 3.x and including apparmor v2.x ruleset compatibility patches from Canonical at the moment.

Well apparmor_parser is exhibiting different issues after further testing so going to hold off with systemd update + kernel updates for now.
Is there where I manage to convince everyone to just move over to Flatpak? >.<

One of the most useful use of snap for me on Solus is LXD (Hugo is another example). So you'll have to work hard to convince me...

JoshStrobl added a comment.EditedMar 24 2021, 12:48 PM

I've pulled in all of the apparmor patches for 5.11 from Canonical and there isn't any discernible improvement. @algent has been testing alongside me and there is serious inconsistencies in the behavior of apparmor and snapd at the moment just between our machines. Whether ranging from freezer failures, issues like cannot query current apparmor profile which was supposed to be resolved with 5.10+ (we're on 5.11), exec failures after apparmor profiles are reloaded, etc. This is across two different VMs and two different bare metal devices (my laptop and my desktop).

I've tried an apparmor update locally that enables the apparmor service, which is intended to ensure the apparmor cache is loaded. Reliability of it is questionable as well. Looking at other parties, Fedora doesn't use apparmor but rather SELinux and openSUSE explicitly has disabled apparmor in snapd. Only difference between Arch and us at this point was the service file in apparmor, I've checked kernel config differences and the only cgroup related config flag we didn't have was CONFIG_CGROUP_HUGETLB, and enabling that didn't do anything useful.

Outside of that, only other thing I can think of is aa-lsm-hook and our use of apparmor_parser, but pending further investigation I'd probably just advise we temporarily disable apparmor in snapd. At the very least that'd result in usability for linux-lts users, which is questionable at best atm. It'd be no confinement for snaps, running them in devmode, but they should at least continue to work.

I tried to install LXD after today's batch of updates and I get the following error:

error: cannot perform the following tasks:
- Run install hook of "lxd" snap if present (run hook "install": 
-----
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement
execv failed: No such file or directory
-----)

Same error with Chromium and snap-store. I tried a strace of the "snap install" command but nothing relevant logged (nothing in journalctl as well).

JoshStrobl closed this task as Resolved.Mar 25 2021, 12:37 AM
JoshStrobl added a subscriber: Girtablulu.

Should be sorted as of rel 61. @Girtablulu found -linkmode external and added it to a patch. For whatever reason, that fixed the apparmor support.

Still think folks should use flatpak instead where possible :P But at least things will not be borked now.

Thank you @Girtablulu, bashing my head up against the wall on this stuff for days was not fun.

Good work! I managed to install LXD and Chromium. Thanks!