Hi Ralph,
sorry for the late reply. I am not an expert on namespaces, and have
thus forwarded your bug to the upstream mailing list.
On Thu, Apr 23, 2026 at 01:08:08AM +1000, Ralph Ronnquist wrote:
> I observed this ina simple test setup, with on ordinary filesystem
> built with {debootstrap --variant=minbase sid FS ...}
>
> First: {unshare -m -p -f chroot FS} will change root into that
> filesystem with unshared mount and pid namespaces.
>
> Next: {mount -t proc proc /proc} will mount the procfs for that pid
> namespace. We see with {ls -l /proc/1/ns/mnt} the identity of the
> unshared mount namespace, which is different from the identity before
> chroot.
>
> But: {nsenter -t 1 -m -- ls -l /proc/1/ns/mnt} shows the identity of
> the host mount namespace -- the outer namespace.
>
> Thus {nsenter -t 1 -m} "escapes" from the unshared namespace to the
> containing namespace. And for example: {nsenter -t 1 -m /bin/sh}
> starts a shell in the outer mount and pid namespace(s)!
>
> This seems to be a severe bug.
>
> Apparently {nsenter -t 1 -m} finds pid 1 in the outer namespace rather
> than in the call pid namespace.
Hopefully someone from upstream can shed a light :-)
Chris
