Snapd 2.76 mountinfo regression affecting steam, docker snaps

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 snapd 2.76, docker run fails when runsc is used. Reverting snapd allows the container to run again, but it would be better to override the denial with mount-observe or something similar to allow runsc to work with docker again 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 all and allow 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

1 Like