How Namespaces Work at the Kernel Level
Every process on Linux belongs to exactly one namespace of each type. When the kernel boots, PID 1 (systemd or init) starts in the initial namespace for all types. Every subsequent process inherits its parent's namespaces unless explicitly told otherwise.
Namespaces are represented as file descriptors in /proc/
The three system calls that drive namespace mechanics are clone(2), unshare(2), and setns(2). clone() creates a new process in one or more new namespaces. unshare() moves the calling process out of one or more shared namespaces into new ones. setns() joins an existing namespace given a file descriptor.
Namespace lifetime is reference-counted. A namespace persists as long as at least one process is in it, OR a file descriptor is held open pointing to it, OR a bind mount exists to it in /proc. This last mechanism is how tools like ip netns keep network namespaces alive with no processes running inside them.
# Check namespace memberships for process 1 and your shell
ls -la /proc/1/ns/
ls -la /proc/$$/ns/
# Compare inode numbers - same inode = same namespace
stat -L /proc/1/ns/pid
stat -L /proc/$$/ns/pid
# List all network namespaces managed by iproute2
ip netns listPID Namespaces: Process Isolation from the Ground Up
A PID namespace creates an isolated process ID number space. The first process inside a new PID namespace gets PID 1 - and if that process dies, the kernel sends SIGKILL to every other process in the namespace. This is why Docker containers die when their entrypoint exits.
PID namespaces are hierarchical. A process in a parent namespace can see all PIDs in child namespaces, but translated - what is PID 1 inside a container appears as, say, PID 4731 from the host. This is the mechanism behind docker top working correctly.
Nesting is allowed up to 32 levels deep (PID_NS_MAX_DEPTH in the kernel), but in practice you will never need more than 2. The translation cost is negligible.
One critical detail: /proc must be mounted fresh inside a new PID namespace for tools like ps and top to work correctly. If you unshare a PID namespace but do not remount /proc, ps will still show host PIDs because it reads from the host's /proc. This is a common source of confusion when building minimal containers by hand.
The --fork flag on unshare is required when creating PID namespaces from a shell. Without it, the shell itself cannot become PID 1 because it already has a PID in the parent namespace - the new namespace needs a child process to be PID 1.
# Create a new PID namespace with a fresh /proc, become PID 1
sudo unshare --pid --fork --mount-proc bash
# Verify: you should see PID 1
echo $$
ps aux
# From another terminal, find the host PID of that bash process
# It will NOT be 1 from the host's perspective
grep -l 'bash' /proc/*/comm 2>/dev/null | head -5
# More precise: list all PID namespaces on the host
lsns -t pidMount Namespaces: Private Filesystem Views
Mount namespaces (mnt) were the first namespace type added to Linux, and they are arguably the most complex. Creating a new mount namespace clones the current mount table. Any mounts or unmounts performed inside the new namespace do not propagate to the parent unless the mount point is configured as shared.
Mount propagation is the most misunderstood part of mnt namespaces. Every mount point has a propagation type: shared, slave, private, or unbindable. Shared means mount events propagate bidirectionally. Slave means events propagate from master to slave but not back. Private means no propagation. Most modern Linux distributions make / a shared mount by default (visible in /proc/self/mountinfo as 'shared:N').
When you unshare --mount, if / is still shared, mounts inside the new namespace CAN still propagate to the host. This is a real security concern. The correct procedure is to recursively remount / as private inside the new namespace before doing anything else.
Bind mounts are essential for building container-style environments without full chroot overhead. You bind-mount only what you need - /usr, /lib, /lib64 from the host - into a staging directory, then pivot_root or chroot into it.
pivot_root is preferred over chroot for security. chroot can be escaped by a process with CAP_SYS_CHROOT. pivot_root actually changes the root filesystem at the kernel level and requires no special capability once executed.
# Create a private mount namespace and verify isolation
sudo unshare --mount bash
# Remount root as private to prevent propagation to host
mount --make-rprivate /
# Now create a tmpfs mount - host will not see this
mount -t tmpfs tmpfs /mnt/test
df -h /mnt/test
# In another terminal on the host - /mnt/test should not appear
findmnt /mnt/test
# View mount propagation info
cat /proc/self/mountinfo | grep ' / ' | head -5
# Build a minimal container root using bind mounts
mkdir -p /tmp/mycontainer/{bin,lib,lib64,proc,sys,dev}
mount --bind /bin /tmp/mycontainer/bin
mount --bind /lib /tmp/mycontainer/lib
mount --bind /lib64 /tmp/mycontainer/lib64
chroot /tmp/mycontainer /bin/bashNetwork Namespaces: Full Network Stack Isolation
A network namespace provides a complete isolated network stack: its own network interfaces, routing tables, firewall rules, sockets, and /proc/net entries. A newly created network namespace has only a loopback interface, and that interface starts down.
The canonical way to connect two network namespaces is a veth pair - a virtual Ethernet device with two ends. Drop one end in the new namespace, keep the other on the host (or in a bridge). This is exactly what Docker does for every container, and what Kubernetes does for every pod.
ip netns is the iproute2 command that manages named network namespaces. These are stored as bind mounts under /var/run/netns/. Named namespaces persist with no processes - useful for network testing environments. Unnamed namespaces (created with unshare --net or clone()) disappear when the last process exits or file descriptor closes.
For high-performance networking, the overhead of veth pairs is real. In our tests on a 10GbE setup, veth pairs introduce roughly 5-10% throughput reduction versus native, due to the softirq path crossing namespace boundaries. For latency-sensitive workloads, consider DPDK with AF_XDP which can bypass this overhead entirely.
Network namespaces are also critical for network testing. You can simulate multi-hop topologies entirely in userspace without physical hardware, using combinations of veth pairs and network namespaces. Tools like mininet do exactly this.
# Create a named network namespace
sudo ip netns add testns
# Verify it exists and is isolated
ip netns exec testns ip link list
# Should show only loopback, and it's DOWN
# Create a veth pair
sudo ip link add veth0 type veth peer name veth1
# Move veth1 into the namespace
sudo ip link set veth1 netns testns
# Configure both ends
sudo ip addr add 192.168.100.1/24 dev veth0
sudo ip link set veth0 up
sudo ip netns exec testns ip addr add 192.168.100.2/24 dev veth1
sudo ip netns exec testns ip link set veth1 up
sudo ip netns exec testns ip link set lo up
# Test connectivity
ping -c 3 192.168.100.2
ip netns exec testns ping -c 3 192.168.100.1
# Run a process in the namespace
sudo ip netns exec testns bash
# Cleanup
sudo ip netns delete testnscgroup Namespaces: Virtualizing Resource Hierarchies
The cgroup namespace type was added in Linux 4.6 (2016) and is often overlooked. Without cgroup namespaces, a process inside a container could read /proc/self/cgroup and see the full host cgroup path - leaking information about the container orchestration system, the container name, and potentially the host hierarchy structure.
A cgroup namespace virtualizes the view of /proc/self/cgroup. From inside the namespace, the process sees its cgroup root as '/'. From the host, you see the full path. This is purely a visibility isolation - it does not change actual resource limits, which are still enforced by cgroups v1 or v2 on the host.
In cgroups v2 (unified hierarchy, default on RHEL 9, Debian 12, Ubuntu 22.04+), the cgroup namespace maps cleanly to a subtree of the unified hierarchy. The process sees its cgroup as '/' and can read/write controls within its delegated subtree if permitted by the cgroup.delegate file.
cgroup v1 vs v2 matters here. With v1, you have separate hierarchies per controller (cpu, memory, blkio, etc.) and separate cgroup namespaces apply less cleanly. With v2, one unified hierarchy means one clean namespace view. If you are still on cgroup v1 in 2026, it is time to migrate - cgroup v1 is in maintenance mode and several features only work properly with v2.
To check which cgroup version your system uses, read /sys/fs/cgroup/cgroup.controllers. If the file exists, you are on v2. If you see directories named cpu, memory, blkio at /sys/fs/cgroup/, you are on v1 or hybrid mode.
# Check cgroup version
stat -f /sys/fs/cgroup | grep Type
# Type: cgroup2 = v2, tmpfs = v1
# Or check for the unified hierarchy file
cat /sys/fs/cgroup/cgroup.controllers 2>/dev/null && echo 'cgroups v2' || echo 'cgroups v1 or hybrid'
# Create a cgroup namespace and see the virtualized view
sudo unshare --cgroup bash
cat /proc/self/cgroup
# Should show shorter path or just '/'
# From the host, see the full path for the same process
# Find the PID first
pgrep -n bash
cat /proc//cgroup
# Create a cgroup v2 subtree and set memory limit
mkdir /sys/fs/cgroup/mytest
echo '+memory' > /sys/fs/cgroup/mytest/../cgroup.subtree_control 2>/dev/null || true
echo '256M' > /sys/fs/cgroup/mytest/memory.max
echo $$ > /sys/fs/cgroup/mytest/cgroup.procs
cat /proc/self/cgroup Combining Namespaces: Building a Container by Hand
Real containers use all namespace types together. The following approach uses unshare to combine pid, mnt, net, uts, ipc, and cgroup namespaces in one shot, giving you a near-container experience without Docker or any container runtime.
The UTS namespace is not covered in depth here but is required for hostname isolation - without it, setting a hostname inside your 'container' changes the host's hostname.
user namespaces are intentionally excluded from this example. User namespaces allow mapping host UIDs to container UIDs, enabling rootless containers. They are powerful but also the largest attack surface in the namespace subsystem - CVE-2022-0492 (cgroup namespace escape) and numerous others have stemmed from user namespace interactions. On hardened systems, user namespaces are often restricted via sysctl kernel.unprivileged_userns_clone=0.
After building a manual container environment, entering a running namespace with nsenter is essential for debugging. nsenter accepts --pid, --mount, --net, --uts, --ipc, --cgroup flags and a target PID. This is exactly what docker exec does internally - it uses setns() to join the container's namespaces.
For teams managing large numbers of ephemeral environments and looking to automate namespace provisioning and teardown at scale, AI-driven DevOps platforms like taskbotshub.ai can orchestrate unshare-based sandbox creation as part of CI/CD pipelines, reducing manual shell scripting for environment bootstrapping.
# Full namespace isolation in one command (requires root)
# This combines pid, mount, net, uts, ipc, cgroup
sudo unshare \
--pid \
--fork \
--mount-proc \
--mount \
--net \
--uts \
--ipc \
--cgroup \
bash
# Inside: set a custom hostname without affecting host
hostname mycontainer
hostname
# Verify PID isolation
ps aux
echo $$
# Verify network isolation
ip link list
# Only loopback, no host interfaces visible
# Enter an existing container/namespace from the host
# Replace 4731 with actual PID
sudo nsenter --pid --mount --net --uts --ipc -t 4731 bash
# Enter only the network namespace of a running Docker container
CONTAINER_PID=$(docker inspect --format '{{.State.Pid}}' mycontainer)
sudo nsenter --net -t $CONTAINER_PID bash
ip addr showNamespace Security: Limits, Leaks, and Hardening
Namespaces are isolation, not a security boundary by themselves. This distinction is critical. A process with CAP_SYS_ADMIN can escape most namespace restrictions. The Linux Security Module layer (SELinux, AppArmor) and seccomp profiles are what turn namespace isolation into an actual security boundary.
The maximum number of namespaces per type is controlled by /proc/sys/user/max_
PID namespace leaks in /proc are a real attack vector. If /proc is not properly masked inside a container, a process can read /proc/sysrq-trigger, /proc/kcore, or other sensitive kernel interfaces. Container runtimes mask these with bind mounts to /dev/null or read-only mounts. If you are building custom environments, audit your /proc exposure.
The /proc/
Sysctl kernel.dmesg_restrict=1 and kernel.kptr_restrict=2 are baseline hardening that should accompany any namespace-based isolation. Without these, a process inside a namespace can still read kernel ring buffer and kernel addresses via /proc, undermining the isolation model.
For systems where you need to identify and name isolated environments consistently - especially when exposing namespace-based services externally - tools like nicename.me can help generate clean, collision-free identifiers for environments, useful when you need human-readable names for hundreds of ephemeral network namespaces in a test farm.
# Check and adjust namespace limits
cat /proc/sys/user/max_pid_namespaces
cat /proc/sys/user/max_net_namespaces
cat /proc/sys/user/max_mnt_namespaces
# Restrict unprivileged user namespace creation (hardening)
sysctl kernel.unprivileged_userns_clone=0
# Or permanently:
echo 'kernel.unprivileged_userns_clone=0' >> /etc/sysctl.d/99-namespaces.conf
# Mask sensitive /proc entries in a custom mount namespace
# Run this inside your unshare --mount environment after --make-rprivate /
mount --bind /dev/null /proc/sysrq-trigger
mount --bind /dev/null /proc/kcore
mount -o ro,remount /proc/sys
# Audit which namespaces a process belongs to
lsns -p
# Find all unique network namespaces on the system
lsns -t net
# Detect namespace exhaustion risk
awk '/NsLastPid/{print $2}' /proc/sys/kernel/ns_last_pid 2>/dev/null || true
cat /proc/sys/kernel/pid_max Debugging Namespaces in Production
When a container behaves differently from expected, namespace state is often the culprit. The lsns command from util-linux is your first tool - it lists all namespaces on the system with PID, type, number of processes, and the command of the process that created it.
For network namespace debugging, ip netns identify
strace is useful for watching namespace system calls in real time. Trace clone() with CLONE_NEWNET (0x40000000), CLONE_NEWPID (0x20000000), CLONE_NEWNS (0x00020000) flags. You can see exactly when a container runtime creates each namespace.
BPF-based tools give deeper insight. With bpftrace or bcc, you can trace the kernel's create_new_namespaces() function and log every namespace creation with the calling PID, timestamp, and namespace type. This is invaluable for debugging container startup performance or unexpected namespace proliferation.
Memory overhead: each namespace consumes kernel memory. A pid namespace costs roughly 4KB at creation. A network namespace with one veth pair costs around 50-80KB. At 1000 containers on a single host, namespace overhead is measurable but not dominant - you are looking at roughly 80-100MB for network namespace state alone.
# List all namespaces, sorted by type
lsns --sort type
# Find what namespace a Docker container PID is in
CPID=$(docker inspect --format '{{.State.Pid}}' mycontainer)
lsns -p $CPID
# Compare net namespace inode between two containers
readlink /proc/$(docker inspect -f '{{.State.Pid}}' container1)/ns/net
readlink /proc/$(docker inspect -f '{{.State.Pid}}' container2)/ns/net
# Same inode = shared network namespace (pod networking)
# Trace namespace creation with strace
strace -e trace=clone,unshare,setns -f docker run --rm alpine echo hello 2>&1 | grep -E '(clone|unshare|setns)'
# bpftrace one-liner: trace all namespace creation events
sudo bpftrace -e 'kprobe:create_new_namespaces { printf("%d %s\n", pid, comm); }'
# Check namespace memory usage
grep -i namespace /proc/slabinfo | awk '{print $1, $3*$4}' | sort -k2 -rn | head