Snapd 2.76 mountinfo regression affecting steam, docker snaps

[ndyer]

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:

• https://www.reddit.com/r/linux_gaming/s/qbdAo6cD2Z
• Snapd 2.76 Release Update - #6 by Yasirel

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: https://github.com/golang/go/issues/77911

The PR https://github.com/canonical/snapd/pull/16982 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

https://github.com/canonical/snapd/pull/17321 is under discussion. We are looking for a release path.

Additional info

Our internal tracking ticket: https://warthogs.atlassian.net/browse/SNAPDENG-37182

[ernestl]

Snapd 2.76.2, which addresses the mountinfo regression has been released.