Following up on comment #52, where I said I could not reproduce this.
I still cannot reproduce it by installing packages, but I can now
reproduce it from David's attached artifacts alone, which narrows things
down considerably.
Reproducing from the attached policies
--------------------------------------
In a fresh Ubuntu 26.04 VM matching the reported environment:
kernel 7.0.0-15-generic (linux-image 7.0.0-15.15)
apparmor/libapparmor1 5.0.0~beta1-0ubuntu7 (pinned, held)
snapd deb 2.75.2+ubuntu26.04.2, upgraded from
2.74.1+ubuntu26.04.4 with snaps already installed
snapd snap 2.75.2 (rev 26865, held) so the deb wins the
re-exec version comparison, as it did for David
firefox rev 8863, latest/stable
apparmor_packet_mediation 0 (same as David's answer in #36)
I load David's two compiled policies straight into the kernel with
"apparmor_parser -B -r" and run a test program under
"aa-exec -p snap.firefox.firefox". Nothing else changes between the two
runs - same kernel, same test, same profile name:
attachment 5974630, "2.75.2 firefox-native.bin"
(host apparmor 5 parser, abi/3.0)
48 denied operations, including inet and inet6 socket creation,
matching the audit records in the original report
attachment 5974631, "2.75.2 firefox-snap.bin"
(apparmor 4 parser vendored in the snapd snap)
0 denials
So the two artifacts genuinely behave differently on the same kernel,
and the difference is in the compiled policy rather than in the rules
snapd writes. That agrees with John's finding in #34 that the profile
text is not the variable, and with David's confirmation in #45 that
SNAP_REEXEC=force restores networking: force is what puts the vendored
apparmor 4 parser back in charge.
What this does not explain yet
------------------------------
A firefox profile generated on my VM, by the same snapd 2.75.2 and
compiled by the same 5.0.0~beta1 parser with the same
--policy-features /etc/apparmor.d/abi/3.0, does NOT reproduce the
denials. Only David's compiled policy does.
That suggests the problem is dependent on profile content rather than on
the parser version alone, which would also explain why it has been hard
to trigger deliberately (John, #48). Worth noting that David's profile is
for org.mozilla.firefox_nightly and carries a different interface set
than a stock latest/stable firefox, so the two profiles are not the same
input.
The obvious next step, which I have not done yet, is to compile David's
profile text (attachment 5973938) with 5.0.0~beta1 specifically, load the
result, and see whether it denies. If it does, this is reproducible from
source and the earlier non-reproduction was down to parser version; if it
does not, then something about how the policy was produced on David's
machine matters.
Things I was able to rule out
-----------------------------
Each of these was tested and did not reproduce the denials:
- apparmor userspace version on its own: pinning 5.0.0~beta1-0ubuntu7
instead of 5.0.2 changes nothing for a locally generated profile
- the upgrade path: installing firefox first, then upgrading
2.74.1 -> 2.75.2 so profiles are regenerated underneath it, with the
apparmor cache deliberately left in place
- SNAP_REEXEC=0, unset, and force, verified by checking which binary
the daemon actually runs rather than what "snap debug execution
apparmor" reports on the client side
- syscall dispatch: libc wrappers, the raw per-operation syscalls, and
the multiplexed socketcall(2) via a 32-bit build, all identical
- user namespaces and network namespaces, and running unprivileged
rather than as root
One incidental finding for tooling
----------------------------------
The same 5.0.0~beta1 parser writes two different blob shapes:
apparmor_parser ... -o out.bin 145443 bytes, starts directly
with the zstd magic 28 b5 2f fd
the same policy as a cache entry 145451 bytes, starts with
01 03 00 ... then the zstd frame
The 8 byte difference is exactly struct compr_user_header. So whether
the header is present depends on -o versus cache output, not on the
parser version - worth knowing for anyone writing tools that read these
files, since firefox-native.bin has no header. (5.0.2 differs again: it
writes -o output uncompressed.)
Reproducer
----------
The test program and the spread tasks are at
https://github.com/zyga/snapd-lp-2154378 (branch main). The key
experiment needs neither snapd nor spread, only the two attachments, a
7.0.0-15 kernel and:
apparmor_parser -B -r firefox-native.bin
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2154378
Title:
Snaps lost internet access after updating snapd to 2.75.2 on Ubuntu
26.04
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/2154378/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
