Namespaces Explained

An engineer asks: "What is a container, actually?" The usual answer, "a lightweight VM", is wrong. A container is not a virtualized machine. It is a normal Linux process that the kernel has lied to. The process sees a filesystem that is not the host's filesystem. It sees a network interface that does not exist outside of it. It sees PID 1 where there is no PID 1 on the host. It sees its own hostname, its own IPC, its own users. None of it is emulated, the kernel simply shows this process a custom view of reality.

The mechanism that enables those lies is namespaces. Seven of them, each isolating one kind of kernel resource. Once you understand namespaces as a list of seven things the kernel can lie about, containers stop being magic, they are a kernel feature you could invoke by hand from a shell. This lesson is that list: what each namespace isolates, how to see them on a running system, and how to build your own.

---

What a Namespace Is

A namespace is a kernel-level abstraction that isolates some class of global resource, so that the processes inside the namespace see a different instance of that resource than processes outside it. The kernel manages many global things: the set of PIDs, the set of mounts, the hostname, the routing table. A namespace says "make a separate set of these, visible only to members of this namespace."

Three operations define the interface:

• clone() or unshare() with one or more CLONE_NEW* flags, creates a new namespace for the calling process.
• setns(), move an existing process into an existing namespace.
• Bind-mounting /proc/[pid]/ns/<kind>, pin a namespace so it outlives its last process (the core trick ip netns add uses).

Every process belongs to one namespace per kind. Linux has seven kinds:

Namespace	CLONE_NEW* flag	What it isolates
mnt	CLONE_NEWNS	The mount table, what is mounted where
pid	CLONE_NEWPID	The PID number space, who is PID 1
net	CLONE_NEWNET	Network interfaces, routing tables, firewall rules, sockets
ipc	CLONE_NEWIPC	System V IPC, POSIX message queues
uts	CLONE_NEWUTS	Hostname and NIS domain name
user	CLONE_NEWUSER	User and group IDs, capabilities
cgroup	CLONE_NEWCGROUP	The view into /sys/fs/cgroup
time (newer)	CLONE_NEWTIME	The monotonic and boot clocks (available but rarely used)

---

Seeing Namespaces on a Live System

Every process has a /proc/[pid]/ns/ directory with a symlink per namespace kind. The symlink's target contains a unique inode, two processes with the same inode are in the same namespace.

# Your shell's namespaces
ls -l /proc/$$/ns
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 cgroup -> 'cgroup:[4026531835]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 ipc    -> 'ipc:[4026531839]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 mnt    -> 'mnt:[4026531840]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 net    -> 'net:[4026531992]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 pid    -> 'pid:[4026531836]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 time   -> 'time:[4026531834]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 user   -> 'user:[4026531837]'
# lrwxrwxrwx 1 admin admin 0 Apr 19 10:00 uts    -> 'uts:[4026531838]'

# Compare with a containerized process — find a container PID on the host
pgrep -f nginx | head -1                   # pick any running container process
ls -l /proc/$PID/ns
# Some inodes differ — those are the namespaces the container runtime created

# Group processes by what namespace they live in
lsns                         # list every namespace on the system
# NS         TYPE   NPROCS  PID USER   COMMAND
# 4026531836 pid        245    1 root   /lib/systemd/systemd
# 4026532420 pid          8 12345 65535 nginx: master
# 4026532421 net          8 12345 65535 nginx: master
# 4026532422 mnt          8 12345 65535 nginx: master
# ...

# Just one kind of namespace
lsns --type net

If two processes have the same inode for net:, they share a network namespace (same interfaces, same routing table). The host and a container almost always differ on mnt, pid, net, and uts; they may share ipc and user depending on the runtime.

---

The Seven Namespaces in Detail

mnt: Mount Namespace

Isolates the mount table. A process in its own mnt namespace sees a different set of mounts from the host, the same kernel, a different view of the filesystem tree.

This is what lets a container have / be its overlay rootfs while the host has / on nvme0n1p2. The container's mounts do not appear on the host, and the host's mounts do not appear in the container (unless the runtime explicitly bind-mounts them in).

# Inside the container's mount namespace
sudo nsenter -t $CPID -m -- cat /proc/self/mountinfo | head -5
# Different from the host's /proc/self/mountinfo

# Or create one by hand right now
sudo unshare -m bash
# Inside: every mount you make is invisible to the host
mount -t tmpfs tmpfs /tmp
findmnt /tmp
exit
# Back in the host: /tmp is still its original mount

pid: PID Namespace

Isolates the PID number space. The first process in a new PID namespace gets PID 1. It is also the namespace's init, if it dies, every process in the namespace dies with it.

# Create a new PID namespace — the shell inside is PID 1
sudo unshare --pid --fork --mount-proc bash
# Inside:
ps aux
# USER   PID ... COMMAND
# root     1 ... bash        <- our shell is PID 1
# root     8 ... ps
# nothing from the host is visible
# Exit the shell and the namespace is cleaned up
exit

Two important properties:

• PIDs in a child namespace are different numbers from the host. The same process has a different PID depending on which namespace is asking.
• The host can still see every process: it just sees them with their host-side PIDs. /proc/$HOSTPID/status shows the NSpid: field, which lists the PIDs this process has in each namespace it belongs to.

net: Network Namespace

Isolates networking: interfaces, routing tables, ARP tables, firewall rules (iptables/nftables), sockets. Inside a fresh net namespace you see only the loopback (lo) and you need to add interfaces to it, typically by moving a veth pair in from the host.

# Create a network namespace with the iproute2 tool
sudo ip netns add demo
sudo ip netns list
# demo

# Run a command in it
sudo ip netns exec demo ip link
# 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN ...
# only lo — no eth0, no wireless, nothing

# Bring lo up inside it
sudo ip netns exec demo ip link set lo up
sudo ip netns exec demo ip addr
# 1: lo: <LOOPBACK,UP> ... inet 127.0.0.1/8 ...

# Clean up
sudo ip netns del demo

All container networking (Docker bridges, Kubernetes CNI plugins, Istio sidecars) is built on manipulations of network namespaces: create the namespace, add a virtual interface (veth) with one end inside and one end on the host, set up routing, apply iptables rules, done.

ipc: IPC Namespace

Isolates System V IPC (shared memory segments, message queues, semaphores) and POSIX message queues. Processes in different IPC namespaces cannot see each other's IPC objects.

This matters for legacy software that uses shmget() / msgget() / semget(), multiple instances in separate containers will not collide. For modern code, which mostly uses Unix sockets or shared memory via shm_open()/mmap(), this namespace rarely affects you.

ipcs                              # see IPC objects in your namespace
# ------ Message Queues --------
# ...
# ------ Shared Memory Segments --------
# ...
# ------ Semaphore Arrays --------
# ...

sudo unshare --ipc bash           # new IPC namespace
ipcs                              # completely empty — host's IPC not visible

uts: UTS Namespace

Isolates hostname and NIS domain. Lets a container sethostname("web-01") without affecting the host.

hostname
# host.example.com

sudo unshare --uts bash
hostname container-1
hostname
# container-1         <- changed inside the namespace
exit

hostname
# host.example.com    <- host unaffected

Small namespace, but every container runtime uses it, hostname inside a pod reporting the pod name or something else the runtime chose is pure UTS namespace at work.

user: User Namespace

The most powerful and dangerous one. Isolates user IDs and group IDs, a process can be UID 0 (root) inside the namespace while being a regular unprivileged user on the host. Combined with capabilities, this is how rootless containers work.

# Create a user namespace and map your host UID 1000 to UID 0 inside
unshare --user --map-root-user bash
# Inside:
id
# uid=0(root) gid=0(root) groups=0(root),...

cat /proc/self/uid_map
# 0       1000     1                <- inside UID 0 = host UID 1000

# But real privileges are still limited — can't chown host files
touch /etc/hosts
# Touch: cannot touch '/etc/hosts': Permission denied
exit

User namespaces are how Docker-rootless, Podman, and Kubernetes' user-namespace support let non-root host users run containers with "root" inside. It is a big deal for security: a container escape as "root-in-namespace" still lands on the host as UID 1000, limiting blast radius.

cgroup: Cgroup Namespace

Isolates the view into /sys/fs/cgroup. Processes in a cgroup namespace see their cgroup hierarchy rooted at their own cgroup, not the host's.

Before cgroup namespaces existed, a container could cat /proc/self/cgroup and see /docker/abc123..., exposing the container runtime's paths. With cgroup namespaces, it sees /, a clean, rooted view.

cat /proc/self/cgroup
# 0::/user.slice/user-1000.slice/session-3.scope

# Inside a container (with a cgroup namespace):
# cat /proc/self/cgroup
# 0::/                <- rooted at the container's own cgroup

time: Time Namespace

Newer (Linux 5.6+). Isolates CLOCK_MONOTONIC and CLOCK_BOOTTIME, the clocks that count forward from boot. Lets checkpoint/restore tools preserve monotonic time when a process moves between hosts.

Rarely used directly. Docker and most container runtimes do not use it today.

---

How Containers Assemble Them

A Docker container typically creates new namespaces for:

• mnt, so the overlay rootfs is the container's /.
• pid, so the container has its own PID 1.
• net, so the container has its own interfaces (unless --network=host).
• uts, so the container can set its own hostname.
• ipc, for isolation of IPC objects.
• Sometimes user, for rootless mode or explicit user namespace mapping.
• Always cgroup, for a clean cgroup view.

# See what namespaces a specific container uses
docker run -d --name demo alpine sleep 1000
PID=$(docker inspect --format='{{.State.Pid}}' demo)
ls -l /proc/$PID/ns

# Compare to your shell
diff <(ls -l /proc/$$/ns | awk '{print $9, $11}') \
     <(ls -l /proc/$PID/ns | awk '{print $9, $11}')

docker rm -f demo

The differences you will see are exactly the namespaces Docker chose to create a new instance of.

---

Tools That Work With Namespaces

unshare: run a command in new namespaces

# All common namespaces + new hostname + new PID tree
sudo unshare --uts --pid --fork --mount --mount-proc --ipc bash
# Now you are effectively in a mini-container:
hostname sandbox
ps aux
mount -t tmpfs tmpfs /mnt
exit
# Everything dissolves when the shell exits

nsenter: enter an existing namespace

The essential tool for debugging containers from the host.

# Enter all namespaces of a container's PID
sudo nsenter -t $PID -a

# Enter just the network namespace (super handy for debugging container networking)
sudo nsenter -t $PID -n ip addr
sudo nsenter -t $PID -n ss -tlnp

# Enter mount namespace to see what the container sees in the FS
sudo nsenter -t $PID -m ls /etc

ip netns: dedicated to network namespaces

sudo ip netns add lab
sudo ip netns exec lab ip addr
sudo ip netns exec lab bash          # drop into a shell in the namespace
sudo ip netns del lab

lsns: list every namespace

lsns                                 # all of them
lsns --type net                      # just network namespaces
lsns -p 1                            # what namespaces does PID 1 belong to

---

Namespaces Are Not Security

Namespaces isolate resource views. They do not by themselves sandbox a process. A process with CAP_SYS_ADMIN inside a mount namespace can mount arbitrary things. A process with CAP_NET_ADMIN in a network namespace can manipulate routes, and if it can see the host network (shared namespace), it can manipulate the host's. A process that can see /proc or /sys paths outside its namespace can read or write them.

Containers are secure because namespaces are combined with:

• Capabilities: dropping CAP_SYS_ADMIN, CAP_NET_ADMIN, etc. from the container's process.
• seccomp: a BPF filter that blocks specific syscalls (like mount, reboot, kexec_load).
• LSMs: AppArmor or SELinux policies that restrict what the process can touch.
• cgroups: resource limits, preventing one container from starving others.
• User namespaces: root-in-namespace mapped to unprivileged on the host.
• Read-only rootfs / no-new-privileges / dropped SUID, belt-and-suspenders.

A container escape is not a "namespace escape", it is usually finding a syscall or kernel bug that bypasses one of these layers. Namespaces are the enabling primitive, not the security story.

---

Debugging With Namespaces

A few techniques you will reach for:

# Is this process in the same netns as the host? (are they in the same inode?)
sudo readlink /proc/1/ns/net /proc/$PID/ns/net
# net:[4026531992]            <- if same, shared
# net:[4026532421]            <- if different, isolated

# See every container's network connections from the host
for pid in $(pgrep -f containerd-shim | head); do
  echo "=== PID $pid ==="
  sudo nsenter -t $pid -n ss -tanlp 2>/dev/null
done

# Which container is a mystery process in?
grep -E '^[0-9]+' /proc/$PID/cgroup
# 0::/system.slice/docker-abc123deadbeef.scope

# Compare two processes' namespace memberships
diff <(ls -l /proc/$PID1/ns/ | awk '{print $9, $11}') \
     <(ls -l /proc/$PID2/ns/ | awk '{print $9, $11}')

---

Key Concepts Summary

• Namespaces isolate kernel resources. One per kind: mount, PID, network, IPC, UTS, user, cgroup, (time).
• Processes belong to one namespace per kind. /proc/[pid]/ns/<kind> is a symlink with a unique inode, same inode = same namespace.
• Containers are processes in custom namespace sets. No virtualization, just the kernel lying consistently.
• unshare creates; nsenter enters; ip netns manages network namespaces. Learn all three.
• mnt isolates the mount table; net isolates interfaces and routing; pid isolates the PID numbering; uts isolates the hostname. The others (ipc, user, cgroup, time) matter in specific situations.
• User namespaces map UIDs. Root inside can be unprivileged outside, the basis of rootless containers.
• Namespaces are not security alone. They isolate views. Security comes from combining them with capabilities, seccomp, LSMs, cgroups, and rootfs hardening.
• lsns lists every namespace; NSpid in /proc/[pid]/status shows nested PIDs. Core inspection tools.

Common Mistakes

• Treating namespaces as virtualization. They are view isolation, the kernel is still shared, and a bug in one namespace's kernel path affects everyone.
• Assuming the PID inside a container is the same as the host-side PID. They are almost always different, use NSpid: in /proc/[pid]/status or docker inspect to translate.
• Debugging container networking from the host without nsenter. You look at the wrong interfaces and get the wrong answer.
• Running --privileged containers in production. It bypasses the layered security that makes namespaces useful and defeats the whole point.
• Confusing user namespaces with UIDs. A user namespace is a mapping: a process can be root inside while being unprivileged outside, and that is a feature, not a hack.
• Thinking "a network namespace needs DNS configuration." The network namespace has nothing but lo until you add interfaces to it, then it inherits whatever routing you set up, including resolver config in the container's /etc/resolv.conf (which comes from the mount namespace).
• Deleting a network namespace with ip netns del while processes are still inside it. They survive momentarily but lose all network access immediately. Use nsenter to cleanly stop them first.
• Believing that namespace isolation prevents filesystem access. A mount namespace shares the underlying storage; two containers on the same host can fight over page cache, I/O bandwidth, and disk space if they share storage. Namespaces isolate what you see, not what you share.

---