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
