Linux Namespaces

Also Known As

TL;DR

Explanation

Linux namespaces partition kernel resources so that a set of processes sees one instance of a resource while another set sees a different instance. They are the primary isolation primitive behind containers (Docker, Podman, LXC, Kubernetes pods) and are created via the clone(), unshare(), and setns() syscalls. Six classic namespace types each virtualize a different slice of global kernel state. PID namespace: gives processes their own PID number space; the first process becomes PID 1 and cannot see processes outside the namespace. Network (net) namespace: provides isolated network interfaces, routing tables, iptables rules, and sockets - veth pairs and bridges connect them. Mount (mnt) namespace: each namespace has its own mount table, so a bind mount or chroot in one container does not affect the host. IPC namespace: isolates System V IPC objects and POSIX message queues, preventing cross-container shared memory access. UTS namespace: isolates the hostname and domain name, letting each container call sethostname() without affecting peers. User namespace: maps UIDs and GIDs between the container and host, so root inside (UID 0) can be mapped to an unprivileged UID outside - the foundation of rootless containers. Newer additions include cgroup, time, and (pending) syslog namespaces. Namespaces compose with cgroups (which limit resource usage) and capabilities (which restrict privileged operations) to form the complete container sandbox. You can inspect a process's namespaces via /proc/<pid>/ns/, enter one with nsenter, or create them ad hoc with unshare(1). Understanding namespaces is essential for debugging container networking, building secure multi-tenant systems, and reasoning about why a process inside a container behaves differently from the same binary on the host.

Common Misconception

Why It Matters

Common Mistakes

• Confusing namespaces (isolation) with cgroups (resource limits) - you need both for a real container.
• Assuming root inside a container is unprivileged on the host without enabling user namespaces.
• Forgetting that the network namespace starts with only a loopback interface and wondering why outbound traffic fails.
• Running unshare --pid without --fork --mount-proc, leaving /proc still showing host PIDs.
• Treating namespaces as a security boundary equivalent to a VM and skipping seccomp or capability hardening.

Code Examples

# Trying to isolate a process but leaking host state:
unshare --pid bash
# Inside: ps aux still shows ALL host processes!
# Why? --pid alone creates the namespace but /proc is still the
# host's procfs, and bash isn't PID 1 of the new namespace.

# Same problem with networking:
unshare --net bash
# Inside: curl example.com -> fails, no interfaces, no DNS,
# and no veth pair was created to reach the host network.

# Properly isolate PID, mount, and network namespaces:
sudo unshare --pid --fork --mount-proc --uts --ipc --net bash

# Inside the new shell:
hostname container-a              # only changes UTS namespace
ps aux                            # sees only PID 1 (bash) and children
ip link                           # only 'lo', and it's down
ip link set lo up                 # bring loopback up

# Inspect namespaces of a process from outside:
ls -l /proc/$(pgrep -f 'bash$')/ns/
# lrwxrwxrwx ... net -> 'net:[4026532...]'
# lrwxrwxrwx ... pid -> 'pid:[4026532...]'
# lrwxrwxrwx ... mnt -> 'mnt:[4026532...]'

# Enter an existing container's namespaces:
sudo nsenter --target $(pgrep -f myapp) --net --pid --mount

References

• https://man7.org/linux/man-pages/man7/namespaces.7.html
• https://man7.org/linux/man-pages/man1/unshare.1.html
• https://lwn.net/Articles/531114/
• https://man7.org/linux/man-pages/man2/clone.2.html

Tags

Related Terms