Namespaces

Published on:

Most important commands to remember

  • lsns -p PID — inspect the namespaces associated with a process.
  • unshare — run a process in newly created namespaces.
  • hostname — read the hostname visible in the current UTS namespace.

Commands and flags

Command or syntax Meaning
lsns -p $$ Show namespace membership for the current shell; $$ is its process ID.
--user --map-root-user Create a user namespace and map your current identity to root inside it.
--uts Create a separate hostname/domain-name namespace.
sh -c '…' Execute the quoted commands in a child shell.
hostname lab-namespace Set the hostname only in the child’s new UTS namespace.
hostname Print the hostname visible to that process.

The semicolon separates the two child-shell commands. The quoted text is passed to that shell. Root inside this user namespace is not unrestricted root on the host.

The concepts that matter

1. A namespace gives a process a particular view

A Linux namespace scopes a category of kernel resources. Processes in different namespaces can see different hostnames, process-ID spaces, network stacks, or mount arrangements.

Namespaces are separate mechanisms, not one all-or-nothing container switch. A process may have an isolated network namespace while sharing another namespace with its parent. Inspect membership before assuming which parts of the host are hidden.

2. Processes share a namespace by membership

Processes that belong to the same namespace share its view for that resource type. A child normally inherits its parent’s memberships unless creation or later setup chooses otherwise.

Creating a new UTS namespace changes the scope of hostname operations; it does not automatically create a new filesystem or network. This is why changing one visible property can demonstrate a boundary without producing a complete container environment.

3. User namespaces scope privileges

A user namespace maps user and group IDs and scopes capabilities. An unprivileged host user can appear as root inside a suitably configured user namespace without becoming host root.

That mapping is powerful but specific. Access to shared files still follows the applicable identity mappings and permissions. Distribution policy may disable or restrict unprivileged user namespaces; an operation-not-permitted error can reflect that policy rather than an incorrect command.

4. Isolation is not a resource budget

Namespaces primarily determine visibility and scope. They do not by themselves allocate a CPU quota, limit memory, or provide a separate kernel. Linux containers commonly combine them with cgroups, capability restrictions, and other controls.

The shared kernel remains a security boundary to consider. A virtual machine and a namespace-based container therefore provide different isolation structures. Calling a process a container is not enough to identify the controls actually applied.

One small example

Optional: run as your ordinary user on a host that permits the stated namespaces. The example creates only a user namespace and UTS namespace for a short-lived child. Do not change host policy merely to make the demonstration run.

lsns -p $$
hostname
unshare --user --map-root-user --uts sh -c 'hostname lab-namespace; hostname'
hostname

The first and final hostname outputs should match. The child should print lab-namespace, showing that its hostname change did not replace the parent’s value. In lsns, compare namespace types and IDs; visible rows depend on permissions and procfs access.

If unshare fails, the child demonstration did not run. Do not interpret the unchanged host name alone as a successful isolation test. After the child exits, its unreferenced namespaces are released automatically. No files or persistent namespace handles are created.

Keep this idea: A namespace changes which instance of a resource a process sees; it does not automatically limit how much resource the process can consume.