In this lesson, you will learn how to leverage user namespaces to ensure that a process running as root inside a container is mapped to an unprivileged, non-root user on the host kernel.
The Problem: Root-in-Container Equals Root-on-Host
By default, if you start a container as root, the kernel perceives that process as having UID 0. If a container breakout occurs—or if the process interacts with host-mounted filesystems—it could potentially perform privileged operations on the host. We must bridge the gap between the container’s isolated view of identity and the host’s reality.
Implementing User Mapping
The solution lies in the user_namespaces(7) primitive. By creating a user namespace, you can map the container's root (UID 0) to an arbitrary high-numbered UID on the host (e.g., 100000).
When the containerized root attempts to interact with host resources, the kernel checks the mapping. Because the host sees the process as UID 100000, it treats the process as an unprivileged user, effectively nullifying the "root" status inside the container for any cross-namespace interaction.
You configure this mapping via /proc/[pid]/uid_map. A typical mapping looks like this:
# Inside the user namespace process:
# Map container UID 0 to host UID 100000 with a range of 65536
echo "0 100000 65536" > /proc/self/uid_map
Why this works
Once this mapping is active, if the process inside the container tries to modify a file owned by the actual host root, the kernel denies it. The process possesses "root-like" capabilities strictly within its isolated sandbox (the container), but the moment it attempts to affect the host's privileged state, the kernel recognizes its mapped UID 100000, which has no special privileges. This creates a powerful layer of defense-in-depth, ensuring that even a successful exploit inside the container remains confined to the unprivileged boundaries of the host user.
Key Takeaway: By mapping the container’s root user to a non-zero host UID using user namespaces, you enforce the principle of least privilege, ensuring that containerized root accounts lack any administrative authority over the host kernel.