Hi everyone Am 02.09.23 um 13:09 schrieb Antonio Terceiro:
On Fri, Sep 01, 2023 at 11:13:11PM +0000, Mathias Gibbens wrote:I don't think we have a good understanding of the root cause of this issue. Initially we thought this was a known upstream issue with all- but very recent versions of apparmor and a corresponding lxc profile fix [0]. However, it appears this is a different issue that somehow depends on the interaction of bookworm's versions of the kernel, apparmor, and/or lxc.
Nod
A minimal reproducer is to install bookworm and create a container with a systemd service using a hardening option like PrivateNetwork=yes. With the latest bookworm kernel (6.1.38-4), the service will fail. But, grab a kernel from testing (6.4.11-1) and then things work -- with no other changes required. I tried the "oldest" kernel on snapshot.d.o post 6.1 series (6.3.1+1~exp1 [1]) and the service works properly with that version as well. So, something changed in the kernel (either upstream or in Debian's packaging) between 6.1 and 6.3 that "unbreaks" services within lxc containers.
Right, these are my findings as well.I also tested downgrading apparmor to 2.13.6-10 (i.e. the version from oldstable) on a bookworm system.
This was also sufficient to unbreak lxc.So it "looks" like apparmor 3.x makes assumptions about the kernel that are not fulfilled by the kernel 6.1.x in bookworm.
Given that simply installing a newer kernel fixes things, I am hesitant to start making changes to lxc until we actually understand what's changed when running the newer kernel and how it's affecting lxc's behavior.
My main concern is to "stop the bleeding" quickly, so to speak, especially/mainly for debci.
I guess we have three options here: a/ upgrade the kernels to the one from backports as suggested by Antoniob/ disable apparmor confinement for lxc on debci via some debci specific configuration c/ disable apparmor confinement for lxc in bookworm via a stable upload of the lxc package
The MR I proposed is c/, as I don't know how to implement a/ or b/.That said, I would be fine with a/ and b/ as well, as this would buy us time to investigate this issue without being under the pressure of causing debci failures. Those debci failures are hard to debug and I would like to avoid having individual maintainers waste time on it.
Do the debci maintainers / lxc maintainers / release team have any preference regarding a/, b/ and c/ ?
Michael
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature