Containers rely on several Linux kernel features, but namespaces provide much of the process-level isolation people notice first. They let different groups of processes see different views of resources such as process IDs, mounts, hostnames, and network interfaces.

You do not need a container runtime to inspect namespaces. Standard Linux tools and /proc expose the relationships directly.

What a namespace changes

A namespace virtualizes one class of global system resource.

Common namespace types include:

  • mnt for mount points;
  • pid for process IDs;
  • net for network devices and routing;
  • uts for hostname and domain name;
  • ipc for System V IPC and POSIX message queues;
  • user for user and group IDs;
  • cgroup for the cgroup namespace view;
  • time on kernels that support time namespaces.

A process participates in one namespace of each supported type.

Namespaces are isolation boundaries, not complete security sandboxes. Permissions, capabilities, cgroups, seccomp, Linux security modules, and filesystem design also matter.

The namespace membership of a process appears under /proc/<pid>/ns:

ls -l /proc/$$/ns

A link looks similar to:

pid -> pid:[4026531836]

The number identifies the namespace object. Two processes whose links show the same namespace type and identifier share that namespace.

Compare the current shell with PID 1:

readlink /proc/$$/ns/mnt
readlink /proc/1/ns/mnt

On a host shell they may match. Inside a container they often differ.

Access to another process’s /proc entries depends on permissions and system hardening settings.

Use lsns for a system-wide view

The lsns command from util-linux summarizes namespaces visible to the caller:

lsns

Filter to one type:

lsns -t pid
lsns -t net

Useful columns include the namespace identifier, type, number of processes, owning user, and a representative command.

On busy systems, visibility can be limited by permissions. Run diagnostics with the least privilege necessary instead of defaulting to an unrestricted root shell.

PID namespaces change process identity

A process can have different PID values depending on which PID namespace observes it.

From the host, a container’s main process might be PID 18420. Inside the container’s PID namespace, the same process can appear as PID 1.

Inspect namespace-specific PID information with:

grep '^NSpid:' /proc/<pid>/status

The values represent PID identities through nested PID namespaces.

This explains why a process ID copied from inside a container may not identify the same numeric PID on the host.

Mount namespaces isolate mount tables

Mount namespaces allow processes to have different mount-point views.

Compare mount namespace IDs:

readlink /proc/$$/ns/mnt
readlink /proc/<pid>/ns/mnt

For a deeper comparison, inspect:

cat /proc/<pid>/mountinfo

mountinfo contains detailed mount relationships and is generally more useful for diagnostics than assuming the host’s mount output represents another process’s view.

Paths visible on the host may not resolve to the same mounted filesystem from the target process.

Network namespaces isolate network stacks

A network namespace has its own interfaces, routes, firewall state, and sockets.

Check membership:

readlink /proc/<pid>/ns/net

A host process and a containerized process often have different namespace IDs.

This is why localhost inside a container usually refers to the container’s own network namespace rather than the host loopback interface.

Enter a namespace with nsenter

nsenter, also from util-linux, can run a command in namespaces associated with another process.

For example:

sudo nsenter --target <pid> --mount --uts --ipc --net --pid /bin/sh

This is powerful, but it changes what the diagnostic shell can see and interact with.

Use it intentionally:

  • identify the target PID first;
  • enter only the namespaces needed;
  • avoid mutating mounts, routes, or process state during read-only investigation;
  • remember that entering a namespace does not reproduce every security property of the target process.

For a network-only check:

sudo nsenter --target <pid> --net ip addr

That is often safer and clearer than entering every namespace.

User namespaces require extra care

User namespaces map user and group IDs between namespace views. A process can appear as UID 0 inside its user namespace without being equivalent to unrestricted host root.

Inspect mappings:

cat /proc/<pid>/uid_map
cat /proc/<pid>/gid_map

Do not infer host privilege solely from a username or numeric UID shown inside a container.

Namespaces and cgroups solve different problems

Namespaces primarily answer “what can this process see?” Cgroups answer questions about grouping and resource control such as CPU and memory limits.

Container runtimes typically use both. A process can be isolated in namespaces but have no useful resource limit if cgroups are not configured.

Common pitfalls

Treating namespace isolation as a complete security boundary

A secure container design also considers capabilities, syscall filtering, filesystem permissions, kernel exposure, and runtime configuration.

Comparing only process IDs

PID numbers are namespace-relative. Compare namespace membership and NSpid when identities are confusing.

Assuming host paths match container paths

Mount namespaces can expose different mount trees.

Using nsenter as a first resort

Start with /proc, lsns, and targeted read-only commands. Enter another namespace only when the extra visibility is necessary.

A reliable diagnostic workflow

When process visibility looks inconsistent:

  1. identify the host PID;
  2. inspect /proc/<pid>/ns;
  3. compare relevant namespace IDs;
  4. inspect namespace-specific state such as mountinfo, routes, or NSpid;
  5. use a narrowly scoped nsenter command if required.

Namespaces become easier to reason about once you stop treating a container as a separate machine and instead inspect which kernel views its processes actually share.

Linux Namespaces Containers Operations