Hi Christian,
Christian Boltz (2021-11-08):
> Your patch looks like something that should (also?) be fixed upstream.
My understanding is that the problem here is caused by a Debian patch:
https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/master/debian/patches/debian/Make-the-systemd-unit-a-no-op-in-containers-with-no-inter.patch
I could trace the history of that patch back to 2012 (2.7.102-0ubuntu3):
* debian/apparmor.init: do nothing in a container. This can be
removed once stacked profiles are supported and used by lxc.
(LP: #978297)
So I believe upstream is not affected, because it'll try to load the
AppArmor policy even inside the kind of containers where it will fail
(that is, most kinds).
I'm going to drop this patch in Debian, which should fix the problem
this bug report is about, because:
- As we can see here, this patch causes trouble in some environments.
- Most container technologies I'm aware of are closer to application
containers than system containers, and are not going to start the
whole pile of systemd units, so the patch does not matter there.
LXC is the only exception I'm aware of.
- The fact other distros did not need to apply such a patch suggests
it's not necessary for most use cases.
- I don't have any time/energy/motivation anymore to maintain or
upstream myself patches that were initially created as part of the
Ubuntu delta to meet Canonical's strategic goals & deadlines, and
never pushed upstream. I'm still immensely grateful by the work
done upstream by Canonical employees, though!
If removing the patch causes trouble for some sort of LXC containers
(there are multiple ways they can or cannot handle AppArmor, depending
on versions, system configuration, per-container configuration, I lost
track), I'll report this upstream and hopefully a LXC-friendly
solution will be implemented there by those of us who particularly
care about LXC :)
Cheers!
