Process Isolation: One Kernel, Many PID 1s

Draw the host kernel as one box. Above it, two containers, each with a process 1 and a process 2. Inside container A, ps shows PIDs 1 and 2; inside container B, ps shows PIDs 1 and 2; on the host, ps shows four processes with PIDs like 28914, 28960, 31007 and 31040 — and every other host process besides. There is one scheduler (Scheduling Simulator: FCFS, Round Robin, Priority) choosing among all of them, one page allocator serving all of them, one network stack, one set of drivers. The containers are not *on top of* anything; they are *inside* the same process table with a different index.

A PID namespace is a mapping from *local* PIDs to *global* task structures. Every process has a PID in its own namespace and in each ancestor namespace, and the kernel exposes both: /proc/<pid>/status on the host has an NSpid: line listing the process’s PID at every level. The namespaces nest: container A’s PID namespace is a child of the host’s (the “initial” namespace), so the host can see into A, but A cannot see the host or B. docker exec works by joining A’s namespaces with setns() from the host side, where visibility is allowed.

The first process created in a new PID namespace gets PID 1 there and inherits init’s special rules (Signals: Asynchronous Notifications From the Kernel): the kernel does not apply default signal actions to it, so a SIGTERM with no handler is silently ignored — the reason docker stop on a naive image waits its full grace period and then SIGKILLs. If PID 1 exits, the kernel kills every other process in the namespace with SIGKILL; there is no container without its init. And every orphaned process in the namespace is reparented to PID 1, which must wait() for them or they stay zombies (Process States). Real init systems do all of this; a Node server or a Python script does none of it, which is why tini exists and why docker run --init injects it.

What the container *sees* is the intersection of all its namespaces: its own process list, its own / (mount), its own interfaces and ports (net), its own hostname (uts), its own shared-memory segments (ipc). What it *does not* see but still shares: the kernel version (uname -r is the host’s), the kernel’s tunables in /proc/sys (mostly host-global; a few like net.* are per-net-namespace), the loaded modules, the clock, the hardware description in /proc/cpuinfo, and — critically — the kernel’s memory and its bugs.

Every system call from every container enters the same kernel code. A vulnerability in that code — a race in a driver, a missing bounds check in a filesystem — is reachable from inside any container that is allowed to make the triggering syscall, and a successful exploit runs with the kernel’s privileges, above every namespace. That is a container escape: not a hole in Docker, a hole in the shared floor. Dirty COW (CVE-2016-5195, a race in Copy-on-Write handling that let an unprivileged process write to read-only mappings) and Dirty Pipe (CVE-2022-0847, uninitialised flags in the Pipes: A Kernel Buffer Between Two Processes buffer allowing overwrites of page-cache pages) were both exploitable from inside containers to gain root on the host.

This is the principled difference from a VM. A hypervisor’s attack surface is the virtual hardware interface — a few dozen device emulations — while a container’s attack surface is the entire syscall table, ~450 entries on x86-64, plus every filesystem and driver behind them. seccomp reduces the reachable surface (Containers Are Processes With the Kernel’s View Narrowed); it does not change the fact that one kernel serves everyone. Multi-tenant platforms that run untrusted code therefore do not rely on containers alone (VM vs Container: Where the Boundary Is).

By default the user namespace is *not* used: uid 0 in the container is uid 0 on the host, restricted only by capabilities and seccomp. If a process escapes the mount namespace — say, through a misconfigured bind mount — it is root on the host filesystem. A user namespace breaks that identity: /proc/<pid>/uid_map maps container uid 0 to an unprivileged host uid such as 100000, and container uids 1–65535 to 100001–165535. Root inside has full capabilities *within the namespace* — it can mount, chown and bind low ports on its own resources — but any access that reaches host objects is checked against uid 100000, which owns nothing.

Rootless containers (Podman by default, Docker in rootless mode) go one step further and run the container runtime itself as an unprivileged user, with the user namespace providing the fake root. Nothing in the chain ever holds real root, so a full escape from every namespace lands as an ordinary user. The costs are real but shrinking: networking needs a user-space helper (slirp4netns or pasta) because creating a veth pair on the host requires privilege, overlayfs needed kernel 5.11+ to work unprivileged, and some images assume they can chown to arbitrary uids. Kubernetes exposes the same idea as hostUsers: false.