User Namespace and ID Mapping

In this lesson, you will learn how to bridge the gap between container-internal users and host-level permissions using ID mapping.

When you create a User Namespace, the root user inside the container (UID 0) does not automatically have root privileges on your host machine. Instead, Linux uses a mapping mechanism that tells the kernel: "When the user inside the container claims to be UID 0, represent them as a high-numbered, unprivileged UID on the host system." This ensures that even if a container process "escapes," it possesses no more authority than a standard, non-privileged user on your host.

To define these boundaries, we use the /proc/self/uid_map and /proc/self/gid_map files. Each entry in these files follows the format: container-id host-id length.

A Practical Mapping Example

Imagine you want to map a range of 1,000 IDs starting from the container’s UID 0 to the host’s UID 100000. You would write the following to the uid_map file:

# container_uid host_uid range
echo "0 100000 1000" > /proc/self/uid_map

In this setup:

• The container’s UID 0 is effectively the host’s UID 100000.
• The container’s UID 999 is the host’s UID 100999.
• Any attempt by the container to access files owned by UID 0 on the host will be rejected, because the kernel sees the request coming from UID 100000 (which likely lacks the necessary filesystem permissions).

This mapping is unidirectional and strictly enforced. By restricting containerized processes to a non-overlapping range of host IDs, you effectively sandbox the container’s "root" user. Even if a process gains full control within its own namespace, it remains a "nobody" on your physical host, preventing it from modifying system configuration files, interacting with host devices, or escalating privileges. This isolation is the bedrock of secure containerization, allowing you to run untrusted code without granting it actual administrative access to your kernel or host environment.

Key Takeaway: ID mapping acts as a secure translator that maps container-internal user IDs to an isolated, unprivileged range on the host, ensuring that "root" inside the container is nothing more than an unprivileged user to the Linux kernel.