Alexander Mikhalitsyn

>I wasn't disagreeing with you, I was just saying I realized why you weren't able to reproduce the issue. I understand that you are not disagreeing, just wanted to point...

Temporary workaround (please, do **inside** the container): ``` vim /etc/apparmor.d/runc # add "pivot_root," line systemctl reload apparmor.service ```

Okay, it is clearly a Ubuntu kernel issue: ``` diff --git a/security/apparmor/mount.c b/security/apparmor/mount.c index 74b7293ab971..b12e6bdfefb2 100644 --- a/security/apparmor/mount.c +++ b/security/apparmor/mount.c @@ -678,7 +678,7 @@ static struct aa_label *build_pivotroot(const struct cred...

https://bugs.launchpad.net/apparmor/+bug/2067900

Hi @softwarecreations please, describe your setup. You have a bare-metal host with Ubuntu 24.04 and you run LXC (not LXD) containers on it? Or you are trying to run LXC...

@bboozzoo Dear Maciej, thanks a lot for so detailed report and analysis. The reason for this quite limited interception support in LXD is that eBPF subsystem in the Linux kernel...

Just today we've got another case. This time it is `BPF_PROG_TYPE_CGROUP_SKB` program type (for nvidia/docker integration).

First of all, AFAIK `/proc/sys/kernel/unprivileged_userns_clone` was always Debian/Ubuntu-specific thing. Upstream kernels behavior equivalent to `unprivileged_userns_clone=1`. And yes, we rely on this thing in nesting support and if we want to...

> because LXD runs as root and we already apply our own apparmor profile to containers when we launch them this shouldnt be too much of an issue. LXD runs...

> Yes but if the init process of the container has been started with an apparmor profile that allows unprivileged namespace creation then the sub-processes should be able to do...