Dear Maintainer,

After installing snapd on a fresh installation (buster, then upgraded to
bullseye), while snaps in general run, snaps requiring network access
fail for lack of it. Specifically tested: tldr, wormhole, bw, chromium,
snap-store; producing various errors, including ENOTFOUND, "Unable to create
socket: Permission denied", et. al.)

This appears to be an AppArmor-related issue. Examining the system log
reveals the following messages:

Oct 27 10:12:08 localhost kernel: [47344.839719] audit: type=1400 audit(1572189128.786:44499): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
Oct 27 10:12:08 localhost kernel: [47344.839724] audit: type=1400 audit(1572189128.786:44500): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
Oct 27 10:12:08 localhost kernel: [47344.839726] audit: type=1400 audit(1572189128.786:44501): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="unix" sock_type="stream" protocol=0 requested_mask="create" denied_mask="create" addr=none
Oct 27 10:12:08 localhost kernel: [47344.840289] audit: type=1400 audit(1572189128.786:44502): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="inet" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create"
Oct 27 10:12:08 localhost kernel: [47344.840292] audit: type=1400 audit(1572189128.786:44503): apparmor="DENIED" operation="create" profile="snap.tldr.tldr" pid=12308 comm="node" family="inet" sock_type="dgram" protocol=0 requested_mask="create" denied_mask="create"

When tested with the tldr snap, and similar messages for other network-
using snaps. If it is an AppArmor issue, this would also explain why
simply installing snaps in --devmode works around the problem, although
hardly optimally.

(Additional note: This is under WSL 2, but I don't think that that's relevant;
I'm using genie to run it inside a systemd bottle, and this exact same
configuration worked perfectly on buster.)

Other information:

# snap version
snap    2.42
snapd   2.42
series  16
debian  -
kernel  4.19.79-microsoft-custom-02210-g78eeb8c7a016-dirty

# snap debug confinement
strict

# snap debug connectivity
Connectivity status:
 * PASS

# snap debug sandbox-features
apparmor:             kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:network_v8 kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:full
confinement-options:  classic devmode strict
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per- snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-actlog bpf-argument-filtering kernel:allow kernel:errno kernel:kill_process  kernel:kill_thread kernel:log kernel:trace kernel:trap
udev:                 device-cgroup-v1 tagging

I looked at the AppArmor profiles for these myself, but unfortunately I'm not
yet familiar enough with AppArmor to spot any issues there might be.