Linux / Advanced: boundaries, security, and recovery / Lesson 14

Understand namespace boundaries

Explain the Linux primitives behind containers and inspect isolation boundaries without creating privileged namespaces.

About 4 min readContent reviewed 2026-10-23

On this page

Lesson goals

Describe what each major namespace isolates.
Interpret namespace membership and user-ID mapping.
Recognize the limits of containers and chroot.

Isolation changes a process’s view

A namespace presents an isolated instance of selected kernel resources to its members. Mount namespaces separate mount views; network namespaces separate network stacks; PID namespaces provide process-ID views; UTS namespaces isolate hostname settings. IPC and time namespaces cover other resource classes. A container combines several such mechanisms with filesystem images, credentials, resource controls, and a runtime’s lifecycle policy. It is not merely a directory with an application inside. Two containers can intentionally share a namespace, so a label such as containerized does not identify the actual isolation boundary.

Inspect membership rather than assuming it

/proc/PID/ns contains handles for namespaces associated with a process, subject to permission checks. The link identities can help determine whether two processes share a particular namespace. Comparing only a hostname is insufficient because distinct UTS namespaces can use the same visible name. Namespace membership also has lifetime details: handles and bind mounts can keep a namespace alive after member processes exit. Administrative tools can enter namespaces when authorized, but that changes the investigative context. Read-only inspection of your own shell is enough to learn the model without entering another workload.

bash Inspect the current shell’s namespace handles

readlink /proc/$$/ns/mnt
readlink /proc/$$/ns/net
readlink /proc/$$/ns/user

The numeric identifiers vary. Equal handles for the same namespace type indicate shared membership in the compared context; the example does not create, join, or modify namespaces.

PID and filesystem views are independent

A process can have one PID in a child PID namespace and another in its ancestor. The namespace’s PID 1 has special duties, including reaping orphaned descendants, and special signal behavior. A mounted /proc must correspond to the intended PID view for useful inspection. Mount namespaces change which mounts are visible, but do not automatically copy file data; a writable bind mount can expose the host’s underlying files. Review every writable mount and shared propagation choice because an isolated-looking path can still refer to shared durable storage.

Root names do not imply the same authority

User namespaces map user and group IDs between contexts and scope capabilities. UID 0 inside a user namespace can correspond to an unprivileged host ID, which enables rootless designs. However, available mappings and namespace creation are constrained by host policy, runtime setup, and kernel configuration. An unprivileged creation capability in the kernel documentation does not guarantee that a particular distribution permits it. Mapping also affects ownership of shared files. Examine the mapping tables and runtime policy before deciding that an apparent root process has host-level authority or that a shared file is safely writable.

bash Read identity mapping and resource-group membership

cat /proc/$$/uid_map
cat /proc/$$/gid_map
cat /proc/$$/cgroup

These files describe this shell’s context. Each mapping row contains an inside start, outside start, and range length. The cgroup file is separate evidence of resource organization, not a namespace guarantee.

Containers share a kernel and need layered controls

Namespaces do not independently limit memory consumption, block dangerous system calls, or grant a trusted image supply chain. Cgroups, capabilities, seccomp, mandatory access controls, read-only filesystems, and runtime policy fill different roles. A privileged container or exposed management socket can collapse intended boundaries. chroot alone changes root-path lookup and lacks these broader controls. Evaluate the actual threat model and inspect runtime configuration rather than claiming a universal security guarantee. Keep host kernels and supported runtimes updated, and avoid giving a lab container sensitive host directories simply to make an example convenient.

Common errors and fixes

Container root is assumed to equal host root

Why it happens: User mapping and capability scope were ignored.
How to fix it: Inspect uid_map and runtime privileges.
Prevent it next time: Describe authority with mappings and capabilities.

An isolated path is assumed to contain copied data

Why it happens: Mount visibility was confused with storage duplication.
How to fix it: Inspect bind mounts and writable shared volumes.
Prevent it next time: Review storage sharing as a separate boundary.

Namespace isolation is expected to limit memory

Why it happens: Resource accounting was confused with resource views.
How to fix it: Review cgroup policy for the workload.
Prevent it next time: Map each requirement to its specific kernel mechanism.

Check your understanding

1. Two processes show the same hostname. Does that prove shared UTS membership?

Show worked solution

No. Separate UTS namespaces can use identical names. Compare authorized namespace handles for that type, accounting for the observation context. A visible label is a value inside the namespace, not a unique identity for the namespace itself.

2. A rootless container cannot edit a bind-mounted project. What should be inspected before broadening permissions?