We are seeing reports of a regression in snapd 2.76.
This currently has been seen to affect the following snaps.
docker snap
Reported in https://github.com/canonical/docker-snap/issues/386
When using
snapd2.76,docker runfails whenrunscis used. Revertingsnapdallows the container to run again, but it would be better to override the denial withmount-observeor something similar to allowrunscto work withdockeragain on the newer versions.
steam snap
Reports:
Workaround:
snap connect steam:mount-observe
As a workaround, @jslarraz has approved automatic connection of mount-observe for the steam snap, so new installs (or reinstalls) will automatically work.
Discussion of issue
The background is that the golang runtime from version 1.25 had introduced code to read /proc/self/mountinfo to determine an appropriate setting for GOMAXPROCS.
With apparmor confinement, this path is not permitted and results in numerous permission denied warning logs.
We raised this as an issue with golang: runtime: bypass reading /proc/self/cgroup and /proc/self/mountinfo when GODEBUG=containermaxprocs=0 · Issue #77911 · golang/go · GitHub
The PR interfaces: conditionally deny /proc/self/mountinfo by miguelpires · Pull Request #16982 · canonical/snapd · GitHub was intended to provide a workaround by allowing access to the mountinfo file by any snap with the appropriate interface. This fix was released in snapd 2.76.
However, this has had a unintended knock-on interaction with rules such as:
@{PROC}/** r,allow allandallow file(as in steam-support)
Proposed fix
i/builtin: fix mountinfo denial for steam/docker interfaces by miguelpires · Pull Request #17321 · canonical/snapd · GitHub is under discussion. We are looking for a release path.
Additional info
Our internal tracking ticket: https://warthogs.atlassian.net/browse/SNAPDENG-37182