On Linux, how does a user namespace let an unprivileged user become UID 0 inside it, and why does that root not give them root on the host?

## The idea A user namespace is the one namespace type that changes *identity* rather than a view of some resource. Inside it, a process has a UID and GID drawn from a private ID space, and it holds a capability set relative to that namespace. The kernel translates between inside IDs and outside IDs at every boundary crossing. The important consequence is that user namespaces are the root of unprivileged isolation: creating one grants the creator a full capability set within it, and that is enough to then create mount, PID, network, UTS and IPC namespaces underneath — operations that normally require `CAP_SYS_ADMIN`. That is precisely how an ordinary user can build an isolated environment without ever being root on the host. ## Writing the maps A fresh user namespace has no mapping at all; until one is written, every ID inside resolves to the overflow ID (conventionally 65534, `nobody`). The mapping is installed by writing to two files on the process: ```bash # format: inside-id outside-id count echo '0 1000 1' > /proc/$PID/uid_map echo 'deny' > /proc/$PID/setgroups echo '0 1000 1' > /proc/$PID/gid_map ``` The rules the kernel enforces are worth knowing verbatim, because they are what makes the feature safe: - Each map file may be written **once**. After that it is immutable for the life of the namespace. - A process **without** `CAP_SETUID` in the *parent* user namespace may write only a single line mapping its own effective UID. It cannot invent a range. - Writing `gid_map` as an unprivileged process requires first writing `deny` to `/proc/<pid>/setgroups`, permanently disabling `setgroups(2)` in that namespace. Without that restriction a process could use a namespace to *drop* a supplementary group and thereby gain access to a file whose group permissions were more restrictive than its other permissions. - The writer must have the right to the target IDs; a broader mapping is delegated by an administrator through `/etc/subuid` and `/etc/subgid` and applied by the setuid-root helpers `newuidmap(1)` and `newgidmap(1)`. So `unshare --user --map-root-user bash` gives you a shell where `id` reports `uid=0(root)`, and `cat /proc/self/uid_map` shows the single line proving what that 0 really is. ## Why it is not root Two separate mechanisms keep this contained. **Capabilities are namespaced.** A capability is always held *with respect to* a user namespace. Holding `CAP_SYS_ADMIN` in a child user namespace lets you act on objects that namespace owns — mounts you created in a mount namespace owned by it, interfaces in a network namespace owned by it — and nothing else. Operations that touch resources owned by the initial user namespace, such as loading a kernel module or setting the system clock, are refused because you do not hold the capability *there*. **File access uses the translated identity.** When the process touches a file on a host filesystem, the kernel maps its inside UID back to the outside UID (1000 in the example) and performs the ordinary permission check with that. A root-owned file with mode 0600 is unreadable, exactly as it was before. IDs that are not covered by the map do not translate at all — files owned by them appear as `nobody`/`nogroup` and cannot be chowned. The same reasoning covers device access: even as inside-root you cannot open a device node you were not already permitted to open, and mounting most filesystem types is still refused because those mounts would expose host-owned objects. What you *can* mount inside a user-namespace-owned mount namespace is deliberately restricted to safe types like `tmpfs`, `proc` and bind mounts of things you can already reach. ## What it buys, and what it costs The payoff is genuine least privilege. A workload can run as inside-UID 0 — satisfying software that insists on being root — while the kernel treats it as an unprivileged user for everything that leaves the sandbox. If it escapes its mount namespace, it escapes as UID 1000. The cost is kernel attack surface. Creating a user namespace hands an unprivileged user reachability into kernel code paths that previously required root — filesystem mount code, network namespace setup, and so on — and several privilege-escalation bugs have lived exactly there. That is why the kernel offers per-user limits such as the `user.max_user_namespaces` sysctl, and why some distributions ship additional restrictions on unprivileged user-namespace creation and expect administrators to opt in. ## Inspecting it `readlink /proc/<pid>/ns/user` identifies the namespace by inode; two processes showing the same value are in the same one. Reading a process's `uid_map` from outside tells you the whole translation in three numbers, which is usually the fastest way to answer "what is this thing actually running as?" when someone shows you a process that claims to be root.