Namespaces in Isolation

One sh process, two PIDs. Inside the container it is PID 1 with two children and nothing else in the world; on the host it is PID 19555 among ~190 processes — and kill 19570 from outside removes a process the container cannot even name.

Concept

A container is not a box. There is no container object in the Linux kernel, no lightweight VM, nothing that "contains" anything. There is one ordinary process tree on one ordinary kernel, and a set of namespaces — per-process filters that change which entries of a kernel table that process is allowed to see. docker run is a clone() with a few extra flags.

This exercise makes that concrete. You'll take one sh process running in a container and look at it from two directions at once. Then you'll kill it from outside using the number it can't see, and finally build a PID namespace by hand with unshare — no Docker, no image, no daemon — to show there was never any magic.

Mental model: three vantage points, and eight kinds of blindness

The vantage points

On Linux, "inside the container" and "the host" are the only two places you can stand. On macOS there are three, and knowing which one you're standing on is most of the exercise:

If you're on native Linux, everything below works identically — just use your own shell wherever the exercise says Session B, and drop the --pid=host container. The /proc paths, inode numbers, NSpid field and unshare behavior are all kernel features, not Docker ones.

The eight namespaces

ls -l /proc/<pid>/ns/ lists them. Each is a kernel object identified by an inode number; two processes are "in the same namespace" iff they show the same inode. That's the whole ontology.

Setup

Three terminals. A · macOS is your Mac shell, B · Linux VM is a shell on the "host", C · container is a shell inside the container.

A · macOS — start the container under test. It runs a shell with two identifiable children, so there's a small process tree to look at:

docker run -d --name ns-a alpine sh -c 'sleep 4242 & sleep 4243 & wait'

B · Linux VM — --pid=host opts out of the PID namespace; --privileged keeps the kernel from redacting other processes' /proc entries:

docker run --rm -it --privileged --pid=host --cgroupns=host alpine sh

C · container:

docker exec -it ns-a sh

Part 1 — the same processes, twice

What this part tests: whether "the container's processes" and "the host's processes" are two sets of processes or one. Per the mental model there is only ever one process tree, so the two views must be the same processes under different names.

ps -o pid,ppid,args

docker top ns-a

ls /proc/19555/ns/

Part 2 — a namespace is an inode

What this part tests: the claim from the mental model that "same namespace" is literally "same inode number". If the container's sh and the VM's PID 19555 are one process, their namespace inodes must be identical — and both must differ from the VM's own.

ls -l /proc/1/ns/

ls -l /proc/19555/ns/

ls -l /proc/1/ns/
cat /proc/1/comm

grep -E '^(Name|Pid|NSpid|Uid):' /proc/19555/status

ps -o pid,args | grep '[c]ontainerd-shim' | head -2

Part 3 — the isolation is a view, not a wall

What this part tests: the first bullet of the mental model. A namespace controls what a process can name. It does not put the process out of reach of anything outside.

kill 19555

kill 19570

ls /proc/19555/root/
cat /proc/19555/root/etc/hostname

Part 4 — joining one namespace and not the others

What this part tests: the second bullet of the mental model — that the eight namespaces are independent, and "join a container" is not an atomic thing you do.

docker run --rm --pid=container:ns-a alpine ps -o pid,args

nsenter -t 19555 -p -m ps -o pid,args

nsenter -t 19555 -p ps -o pid,args

Part 5 — the other namespaces, side by side

What this part tests: that the remaining namespace types work the same way, and that "disabled" and "empty" are different states.

docker run -d --name ns-b --network none --hostname ns-b-box alpine sleep 3600
docker exec ns-b ls -l /proc/self/ns/
docker exec ns-b ip -o addr show

docker run --rm alpine sh -c 'hostname changed-me; hostname'
docker run --rm --cap-add SYS_ADMIN alpine sh -c 'hostname changed-me; hostname'

docker run --rm --network host alpine sh -c \
  'echo "net ns: $(readlink /proc/self/ns/net)"; ip -o addr show | head -4'

docker exec ns-a cat /proc/self/cgroup     # A
cat /proc/19555/cgroup                     # B

Part 6 — the namespace you didn't get

What this part tests: the one line in step 6's output that was identical between the container and the VM's init. Seven namespaces were unshared for you; the security-critical one was not.

docker run -d --name ns-c --user 1000 alpine sleep 5150
docker exec ns-a id
docker exec ns-c id

ps -o pid,user,args | grep -E '[s]leep 5150|[s]leep 4242'
grep '^Uid:' /proc/19555/status

Part 7 — none of this was Docker

What this part tests: the claim in the concept — that docker run is clone() with flags, and every namespace above is a kernel feature you can reach directly.

readlink /proc/self/ns/pid
ps -o pid,args | wc -l

unshare --pid --fork --mount-proc sh -c 'readlink /proc/self/ns/pid; ps -o pid,args'

unshare --pid --fork sh -c 'echo "pid ns: $(readlink /proc/self/ns/pid)"; echo "my pid: $$"; ps -o pid,args | wc -l; ps -o pid,args | head -3'

hostname
unshare --uts sh -c 'hostname ns-by-hand; hostname'
hostname

What you should see

One sh process that is PID 1 with two children when it looks at itself, and PID 19555 with a containerd-shim parent among ~190 processes when the VM looks at it — with NSpid: 19555 1 in /proc/19555/status recording both facts on one line. Identical namespace inodes (pid:[4026533793]) read from either side, all differing from the VM's initial pid:[4026531836] — except user:[4026531837], which matches. kill 19555 from inside failing with No such process, while kill 19570 from outside silently removes the container's PID 8. A second container joining exactly one of ns-a's eight namespaces and keeping its own hostname. And unshare --pid --fork --mount-proc producing a one-process world with no Docker involved — plus, without --mount-proc, a PID 1 that still lists 198 processes.

Why

Because namespaces virtualize names, not resources. A PID namespace gives the kernel a second table in which to register your process, and /proc shows a process only the table entries reachable from its own. So the container's ps is not lying and the VM's ps is not privileged information — they're two indexes into one list of tasks, and NSpid is the row that holds both keys.

That design forces the asymmetry you saw in Part 3. PID namespaces form a tree; a task gets an ID in its own namespace and in every ancestor. Naming therefore works outward-in only, and permission checks are unaffected by namespaces at all — kill 19570 succeeded because the caller was uid 0 and the target was uid 0, exactly as it would have with no containers in the picture. Nothing consulted the boundary.

It also explains why isolation has to be assembled rather than switched on. Each namespace type is a separate kernel object with a separate CLONE_NEW* flag, and docker run sets seven of them. The eighth, user, it leaves alone — so the uid 0 in your container is the uid 0 that owns the VM. Every practical container-security control (--user, seccomp, dropped capabilities, read-only rootfs, userns-remap) exists to shore up that gap, because namespaces were built to make processes not see each other, which is a different goal from making them safe from each other.

Go deeper

• Make a network namespace persist without a container. In a privileged container (apk add iproute2 first — busybox's ip has no netns subcommand): ip netns add ns-lab && ip netns exec ns-lab ip -o link show lists a namespace with nothing but lo and the tunnel stubs. ip netns is a thin wrapper over unshare --net plus a bind mount of /proc/self/ns/net onto /var/run/netns/ns-lab — which is how a namespace outlives every process in it.
• docker run --rm --uts=host alpine hostname prints docker-desktop, the VM's hostname, against a random container ID for the default. The same flag exists for every namespace type; work through them and note which ones Docker will let you share (--uts, --ipc, --pid, --network, --cgroupns) and which it won't (mnt, user).
• Two containers with --ipc=container:ns-a: apk add util-linux, create a SysV segment with ipcmk -M 1024 in one and list it with ipcs -m in the other, then repeat without the flag and watch it vanish. This is the namespace Postgres and Oracle containers actually care about.
• Nest it: run docker run --rm --privileged docker:dind, start a container inside it, and read NSpid for one of its processes from the B shell. NSpid carries one number per PID namespace the task is visible in, so nesting should lengthen the line — the mechanism from step 7 with the recursion made visible.
• Read man 7 namespaces, then man 7 pid_namespaces for the PID 1 semantics this exercise skipped: PID 1 gets no default signal handlers, so docker stop on a shell that ignores SIGTERM waits the full 10 seconds; and when PID 1 exits, the kernel kills the whole namespace. That's why tini / --init exists.
• The counterpart mechanism: cgroups. Namespaces control what a container can see; cgroups control what it can consume. The cgroup memory limits exercise in the backlog picks up exactly where this one stops.

Sources: man 7 namespaces — the authoritative list, including the NSpid field and the /proc/[pid]/ns/ semantics · man 7 pid_namespaces · man 7 user_namespaces · Docker: isolate containers with a user namespace

Cleanup

Only the containers this exercise created, by name — never prune:

docker rm -f ns-a ns-b ns-c

Then exit the B shell (--rm removes it).