Linux Namespaces

Why namespaces matter

Before namespaces, isolating a workload meant a full virtual machine: a second kernel, emulated hardware, gigabytes of RAM, and seconds of boot time. Namespaces offer a radically cheaper alternative. They let one kernel present many independent, mutually invisible views of itself to different groups of processes — so a container can boot in milliseconds, weigh megabytes, and still believe it is the only thing running on the machine.

The core idea is disarmingly simple. The kernel already tracks global resources: a single process table, one routing table, one hostname, one set of mount points. A namespace wraps one of those global tables in a partition so that processes inside see only their slice. Membership is per-process and inherited by children. Two processes in different network namespaces can both bind TCP port 443; two processes in different PID namespaces can both be "PID 1." Nothing is emulated — the kernel simply consults a different table depending on which namespace the calling process belongs to.

This is the primitive underneath Docker, containerd, Podman, LXC, systemd-nspawn, and the sandbox of every serverless platform. Understanding namespaces is the difference between treating containers as magic and being able to debug why a process inside one can't reach the network, or why "root in the container" is not root on the host.

The eight namespace types

Each namespace type virtualizes exactly one class of global resource. They are fully independent — a process can be in a new network namespace but share the host's PID and mount namespaces, or any other combination.

Namespace	clone flag	Virtualizes	Since
Mount (mnt)	CLONE_NEWNS	The mount table — filesystem mount points and propagation	2.4.19 (2002)
UTS	CLONE_NEWUTS	Hostname and NIS domain name	2.6.19 (2006)
IPC	CLONE_NEWIPC	System V IPC and POSIX message queues	2.6.19 (2006)
PID	CLONE_NEWPID	Process ID number space (own PID 1)	2.6.24 (2008)
Network (net)	CLONE_NEWNET	Interfaces, routes, ports, iptables, ARP	2.6.29 (2009)
User	CLONE_NEWUSER	UID/GID mappings and per-namespace capabilities	3.8 (2013)
Cgroup	CLONE_NEWCGROUP	The cgroup root directory (hides the host cgroup path)	4.6 (2016)
Time	CLONE_NEWTIME	CLOCK_MONOTONIC and CLOCK_BOOTTIME offsets	5.6 (2020)

Note the acronym "UTS" comes from struct utsname, the structure returned by uname(2) — the UTS namespace is precisely what lets a container report its own hostname. The time namespace is the newest and deliberately narrow: it only offsets the monotonic and boottime clocks (so a checkpoint/restored container can preserve uptime), not the wall clock CLOCK_REALTIME.

How it works: the three syscalls

Every namespace is manipulated through three system calls, and knowing which does what is the whole mental model:

• clone(fn, stack, flags, arg) — create a new child process and, for each CLONE_NEW* flag set, place that child into a brand-new namespace of that type. This is a single atomic step: the container's very first process is born already isolated. This is how a runtime spawns a container's init.
• unshare(flags) — do not fork; instead move the calling process out of the namespaces it shares with its parent and into fresh ones. The unshare(1) command-line tool is a thin wrapper. A subtlety: unshare(CLONE_NEWPID) does not move the caller itself into the new PID namespace (its PID can't change) — the next child it forks becomes PID 1 of the new namespace.
• setns(fd, nstype) — join an existing namespace, identified by an open file descriptor to /proc/[pid]/ns/<type>. This is how docker exec and nsenter drop a new shell into a container that is already running.

Namespaces are exposed in the filesystem as magic symlinks under /proc/[pid]/ns/. Each looks like net:[4026531992]; the number is the namespace's inode. Two processes are in the same network namespace exactly when those inode numbers match. A namespace stays alive as long as it has a member process or an open file descriptor / bind-mount referring to it — which is how you keep a network namespace around with no process in it (ip netns add bind-mounts it under /var/run/netns/).

Building a container by hand

The magic dissolves once you assemble a container from the primitives yourself. This shell sequence isolates hostname, PIDs, mounts, and the network — roughly what a container runtime does before execing your program:

# Enter fresh UTS, PID, mount, and network namespaces.
# --fork + --pid together make the shell's child PID 1 of the new PID ns.
# --mount-proc remounts /proc so `ps` reflects the new PID namespace.
sudo unshare --uts --pid --mount --net --fork --mount-proc bash

# Inside — set an isolated hostname (UTS namespace)
hostname container-01

# Only our own processes are visible; this bash is PID 1
ps -e            # -> just bash and ps

# The network namespace starts almost empty: loopback, and it's DOWN
ip link          # -> only "lo", state DOWN
ip route         # -> (nothing)

# Bring loopback up; we still have no route to the outside world yet
ip link set lo up

To actually reach the network, you create a veth pair — a virtual Ethernet cable with two ends. One end goes in the container's net namespace, the other stays on the host and plugs into a bridge that NATs traffic. This is precisely what Docker automates with the docker0 bridge, and what a Kubernetes CNI plugin generalizes to give every pod a routable IP.

The PID namespace and the init problem

The PID namespace deserves special attention because it changes process semantics. The first process in a new PID namespace is PID 1 inside it, and inherits init's two special responsibilities:

1. Reaping orphans. When a process's parent dies, the orphan is reparented to PID 1, which must wait() on it or accumulate a zombie. A container PID 1 that never reaps leaks defunct entries in the process table.
2. Signal semantics and teardown. Signals from other processes to PID 1 are ignored unless it has installed a handler — so a naive PID 1 that doesn't handle SIGTERM won't respond to docker stop and gets SIGKILLed after the grace period. And when PID 1 exits, the kernel SIGKILLs every remaining process in the namespace, collapsing it instantly.

This is the entire reason for lightweight init shims like tini (Docker's --init) or dumb-init: they sit at PID 1, forward signals to your app, and reap zombies. PID namespaces also nest — a PID 1 in an inner namespace has some other, larger PID as seen from the host, so the kernel maintains a mapping per level up to a nesting depth of 32.

User namespaces and rootless containers

The user namespace is the most security-relevant and the trickiest. It maps a contiguous range of UIDs/GIDs inside the namespace to a different range outside, via /proc/[pid]/uid_map and gid_map. A process can therefore be UID 0 — full root — inside its user namespace while being an unprivileged UID like 100000 on the host.

Crucially, capabilities are evaluated per user namespace. "Root in the container" holds every capability within that namespace (it can create other namespaces, mount filesystems it owns, etc.) but holds none of them against the host. This inverts the historic requirement that creating namespaces needs CAP_SYS_ADMIN: an unprivileged user can first create a user namespace (the one type that never required privilege) and, being root inside it, then create all the others. That single trick is the foundation of rootless Docker and Podman — containers with no daemon and no host root at all.

Namespaces vs cgroups — the two halves of a container

The single most common confusion is conflating namespaces with cgroups. They are orthogonal and answer different questions.

	Namespaces	Cgroups
Question answered	What can this process see?	How much can this process use?
Mechanism	Partition the view of a global resource	Meter and cap resource consumption
Governs	PIDs, net stack, mounts, hostname, IPC, UIDs	CPU shares, memory, block I/O, PID count
Prevents "noisy neighbor"?	No — a process can still hog all the CPU/RAM	Yes — hard limits and weights
Prevents seeing host processes?	Yes (PID namespace)	No
Syscall / interface	clone/unshare/setns, /proc/[pid]/ns	cgroupfs at /sys/fs/cgroup (v2)
Kills a runaway process?	No	Yes (memory cgroup → OOM killer)

A useful slogan: namespaces are about isolation, cgroups are about allocation. A container that only used namespaces could still exhaust the host's memory and take down every other container; a container that only used cgroups would still see every host process and share its network. You need both. Docker's --memory, --cpus, and --pids-limit flags configure cgroups; its isolation of PIDs, network, and filesystem is namespaces.

Common misconceptions and pitfalls

• "Namespaces are a security boundary like a VM." No. Every container shares one kernel; a single kernel bug is a potential escape. Namespaces isolate the view, not the attack surface. Real isolation layers on seccomp, dropped capabilities, MAC (AppArmor/SELinux), and often user namespaces — or a microVM (Firecracker, gVisor) for a separate kernel.
• "A new network namespace has connectivity." It starts with only a down loopback and nothing else — no routes, no external interface. You must wire in a veth pair or macvlan to get traffic out.
• "unshare(CLONE_NEWPID) puts me in the new PID namespace." It doesn't — your PID can't change mid-life. Only your next forked child becomes PID 1 of the new namespace. This is why unshare --pid needs --fork.
• "Forgetting to remount /proc." A new PID namespace with the host's /proc still shows host processes to ps. You must mount a fresh proc inside the mount namespace (--mount-proc) for the PID view to be consistent.
• "Root in the container is root on the host." Only if there is no user namespace. With user-namespace remapping, container root maps to an unprivileged host UID and holds no host capabilities.
• "Zombies don't matter." Without a reaping PID 1, orphaned children pile up as defunct entries and can exhaust the PID limit. Use an init shim.

How to inspect namespaces

# List every namespace on the system with owning PIDs
lsns

# See which namespaces a given process belongs to (inode per type)
ls -l /proc/$$/ns/
# lrwxrwxrwx net -> 'net:[4026531992]'  mnt -> 'mnt:[4026531840]' ...

# Two processes share a namespace iff these inode numbers match
readlink /proc/1234/ns/net
readlink /proc/5678/ns/net

# Enter a running container's namespaces (what `docker exec` does)
PID=$(docker inspect -f '{{.State.Pid}}' my-container)
sudo nsenter --target "$PID" --net --pid --mount --uts ip addr

# Run a command in only a new mount + net namespace
sudo unshare --mount --net --fork bash

The inode-matching trick is the ground truth: namespace equality is inode equality on the /proc/[pid]/ns/* magic symlinks. Everything Docker shows you about isolation is ultimately explained by which of those inodes a process shares with the host and with its siblings.