little problem here. Looks like I am not the first with this, but the other threads I found do not provide solutions that apply to my scenario (or that I would understand, lol)
Running Ubuntu Budgie 18.04
Because of my dreaded AMD Ryzen 2400G I use the newest kernels (4.18 RCs) available via UKUU
SOME of my installed snaps work (e.g. Atom), but most (e.g. Gimp, Wordpress, Skrifa, VLC, etc.) crash without error message.
When I start them from a terminal, I get:
`
cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
`
When I boot with an older kernel (4.17.x), most of the Snaps work.
Soā¦ how do I convince Snap to work with bleeding edge kernels?
Thanks for semi-n00b-compatible advice
cheers
Martin
UKUU is a hack that installs mainline kernels from PPAs to your system (which are likely missing the right config options and possibly also patches to make snapd work propery):
@MartinTheWanderer As hinted in the conversation above, the issue is that snapd detects that itās running inside Ubuntu, and expects certain things to work correctly, but they donāt because the kernel is not in fact an Ubuntu kernel. The two alternatives here are to either convince the kernel to work more like an Ubuntu kernel, or convince snapd that this is not in fact a normal Ubuntu system. Hacking /etc/os-release might help, but I agree with @zyga-snapd that we should try to introspect and disable the particular features that are breaking for you automatically if thatās a reasonable amount of work given the benefits.
@zyga-snapd Whoās our go-to person for mount namespace issues in the kernel at the moment? Can we at least tell what specific patch is missing?
I strongly suspect this is related to apparmor more than to anything else. Weāve seen some changing behaviour in this area that results in exactly this issue, readlink /proc/1/ns/mnt being denied. To be certain we need to see the denial run question and check how the upstream kernel treats that operation. Once we have this information we can discuss with the security team where (probably) jj might pinpoint the missing patch.
Interesting and not really logical for me (as someone with - ahem - very limited insight in the inner workings of Snap thingsā¦) that some snaps, namely Atom, do not have that problem and run just fine even with 4.18RC2
BTW I am not doing this to keep you guys busy, lol, damn AMD support in 4.17 is just too buggy, keep getting freezes every couple minutes, hours max, with 4.18 it seems to be fine.
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.
cheers
Martin