AppArmor 3.1.4 fixed a bug in mount rules - before they allowed things that the profile didn't really allow, and now they allow exactly what is specified in the profile. See https://gitlab.com/apparmor/apparmor/-/wikis/Release_Notes_3.1.4 and https://gitlab.com/apparmor/apparmor/-/commit/aff29ef0ee88e18db74a364e7dca1b4c0fa95e47 for details.
This also means that profiles that "somehow worked" before now cause denials because they don't have the mount rules they really need.
https://forum.snapcraft.io/t/apparmor-issue/35461 shows the following line from /var/log/audit/audit.log:
type=AVC msg=audit(1685879595.481:528): apparmor="DENIED" operation="mount" class="mount" info="failed perms check" error=-13 profile="/usr/lib/snapd/snap-confine" name="/tmp/snap.rootfs_uAIbsj/" pid=13661 comm="snap-confine" fstype="tmpfs" srcname="none"
Can you please confirm that you get a similar line in your audit.log when snap fails?
If I got the log message right, adding the following rule to the snap-confine profile should fix the problem:
mount fstype=tmpfs -> /tmp/snap.rootfs_??????/,
That all said, I'll hand over the bug to the (system:snappy/snapd) maintainer - AFAIK the snap profiles are shipped as part of the snapd package.
AppArmor 3.1.4 fixed a bug in mount rules - before they allowed things that the profile didn't really allow, and now they allow exactly what is specified in the profile. See https:/ /gitlab. com/apparmor/ apparmor/ -/wikis/ Release_ Notes_3. 1.4 and https:/ /gitlab. com/apparmor/ apparmor/ -/commit/ aff29ef0ee88e18 db74a364e7dca1b 4c0fa95e47 for details.
This also means that profiles that "somehow worked" before now cause denials because they don't have the mount rules they really need.
https:/ /forum. snapcraft. io/t/apparmor- issue/35461 shows the following line from /var/log/ audit/audit. log:
type=AVC msg=audit( 1685879595. 481:528) : apparmor="DENIED" operation="mount" class="mount" info="failed perms check" error=-13 profile= "/usr/lib/ snapd/snap- confine" name="/ tmp/snap. rootfs_ uAIbsj/ " pid=13661 comm="snap-confine" fstype="tmpfs" srcname="none"
Can you please confirm that you get a similar line in your audit.log when snap fails?
If I got the log message right, adding the following rule to the snap-confine profile should fix the problem:
mount fstype=tmpfs -> /tmp/snap. rootfs_ ??????/ ,
That all said, I'll hand over the bug to the (system: snappy/ snapd) maintainer - AFAIK the snap profiles are shipped as part of the snapd package.