I can't comment on the interaction of AppArmor and overlay with the available information. I can say that we already have these rules:
const dockerSupportConnectedPlugAppArmorCore = ` # These accesses are necessary for Ubuntu Core 16 and 18, likely due to the # version of apparmor or the kernel which doesn't resolve the upper layer of an # overlayfs mount correctly the accesses show up as runc trying to read from # /system-data/var/snap/docker/common/var-lib-docker/overlay2/$SHA/diff/ /system-data/var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/common/{,**/} rwl, /system-data/var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/@{SNAP_REVISION}/{,**/} rwl, ` The denial of 'apparmor="DENIED" operation="open" profile="snap.docker.dockerd" name="/system-data/var/snap/docker/common /var-lib- docker/overlay2/afce643d5ac2c31f46b8c867c35abea776166c6da199fab370c30af17d314fd7-init/diff/.dockerenv" pid=2932 comm="dockerd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0' doesn't match this though, because '.dockerenv' is a file, not a directory. If I were to guess, I'd guess that perhaps the snap is overlaying a file rather than a dir, but again, I don't know for sure. It would be fine to adjust the policy to use this instead: /system-data/var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/common/{,**} rwl, /system-data/var/snap/{@{SNAP_NAME},@{SNAP_INSTANCE_NAME}}/@{SNAP_REVISION}/{,**} rwl, since the snap already has read/write access to these directories when /system-data is not prepended. I've taken a todo to send up a PR for this. ** Also affects: snapd Importance: Undecided Status: New ** Changed in: snapd Status: New => Triaged ** Changed in: snapd Assignee: (unassigned) => Jamie Strandboge (jdstrand) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-raspi2 in Ubuntu. https://bugs.launchpad.net/bugs/1868894 Title: [uc18] docker overlayfs* seems broken Status in snapd: Triaged Status in linux-raspi2 package in Ubuntu: Confirmed Status in linux-raspi2 source package in Bionic: New Bug description: A customer recently reported that 'sudo docker run hello-world' fails on a pi3 or pi4 running UC18. Looking at the journal, the failure appears to be caused by an apparmor denial related docker's overlay2 storage driver. I've tried both the unified and the Pi3 specific UC18 images and both fail with the same error. The same command works fine on other devices running UC18 (I've tested multipass+macOS, and dragonboard), and also works on a Pi3b running our standard UC16 image. Here are the details from the UC18 image. $ snap list core 16-2.43.3 8691 stable canonical✓ core core18 20200124 1673 stable canonical✓ base docker 18.09.9 427 stable canonical✓ - pi 18-1 27 18-pi canonical✓ gadget pi-kernel 5.3.0-1019.21~18.04.1 104 18-pi canonical✓ kernel snapd 2.43.3 6438 stable canonical✓ snapd And here's the apparmor denial: Mar 24 19:38:55 localhost sudo[3095]: awe : TTY=pts/0 ; PWD=/home/awe ; USER=root ; COMMAND=/snap/bin/docker run hello-world Mar 24 19:39:02 localhost audit[2932]: AVC apparmor="DENIED" operation="open" profile="snap.docker.dockerd" name="/system-data/var/snap/docker/common/var-lib-docker/overlay2/afce643d5ac2c31f46b8c867c35abea776166c6da199fab370c30af17d314fd7-init/diff/.dockerenv" pid=2932 comm="dockerd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 I've been told this may end up being something that gets worked around in snapd, however as this looks like a regression, I'm erring on the side of caution and filing this bug anyways. Please let me know if there's anything else I can provide. To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1868894/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp