Ummmmh… guess I was too optimistic about apparmor workarounds…
Probably looking in the wrong place again.
Tried changing the aa profile for e.g. snap.gimp.gimp from enforce to complain, and tried to disable apparmor completely, but still getting the same error when trying to start gimp.
IS there actually a quick and dirty workaround to take apparmor out of the equation temporarily or convince it that these snaps are perfectly fine?
using an ubuntu kernel is the easiest “workaround” here i guess
the confinement is a semi-complex communication between snapd and the involved parts, killing off one side of that communication will not help, both sides need adjustment (which is what zyga is working on) to make it work.
ok, thanks, guess I need to work on a different machine then for now.
Going back to an earlier kernel unfortunately is not an option, it results in frequent freezes thanks to still unreliable support for the Raven Ridge processors with integrated Vega graphics…
Note, this probably isn’t an apparmor change but a capabilities change in the upstream kernel that now triggers this denial. The snap-confine profile seems to need: ptrace (read) peer=unconfined, to read this file.
Hmm, curiously, this is in /etc/apparmor.d/snap.core.4938.usr.lib.snapd.snap-confine:
# support for the mount namespace sharing
capability sys_ptrace,
# allow snap-confine to read /proc/1/ns/mnt
ptrace trace peer=unconfined,
It seems 4.18 changed the check from ‘trace’ to ‘read’. @zyga-snapd, we could adjust to have:
ptrace trace peer=unconfined, # 4.17 and earlier
ptrace read peer=unconfined, # 4.18 and later
though @zyga-snapd, a much better fix would be to have only the ‘ptrace read’ rule in the profile and conditionally add the ‘ptrace trace’ if on kernel <=4.17. The trace rule is really powerful and it would be good to avoid it if possible. We should be able to do this based on the #include mechanisms we use for nfs and overlay.
@MartinTheWanderer, as a workaround, you can add to the /etc/apparmor.d/*snap-confine* files (on a line before the final ‘}’ at the end of the file):
ptrace read peer=unconfined,
then run sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*. You will need to redo this when the core snap refreshes until the proper fix is included.
Actually, I discussed this with John and this was an AppArmor change (well, more precisely, an unrelated change turned the read into a trace and AppArmor needed an adjustment to turn it back into a read, but this adjustment didn’t happen until 4.18). The ‘trace’ was undesirable and should’ve always been ‘read’. He is in the process of rolling that out to all Ubuntu kernels. @zyga-snapd, it would be great to default to read when possible. Eg, if <4.18 and isNotUbuntu, add ptrace trace rule (we’d have to wait for those kernels to rollout of course.
I’ve asked John to add a flag for the backports tree so we can interrogate the kernel for this. So, we can check for the flag or 4.18. Anyone who picks up the patch will just get it.
I’ve upgraded the kernel 4.18.0rc4 to see if the boot problem with my ryzen 2200g was still present (surprisingly it seems to boot reliably now, or at least it seems so) but I couldn’t run snaps anymore.
I just wanted to confirm that the workaround works.
ls /etc/apparmor.d/snap-confine
/etc/apparmor.d/snap.core.4917.usr.lib.snapd.snap-confine
/etc/apparmor.d/usr.lib.snapd.snap-confine.real
There were 2 files, the first one had at line 366:
ptrace trace peer=unconfined,
Same thing second file line 354.