A user namespace isolates security-related identifiers and attributes, especially user IDs, group IDs, capabilities, and related credentials. A process can be UID 0 inside the namespace while remaining unprivileged outside it. Podman uses this mapping to give rootless containers multiple internal UIDs without granting equivalent host privileges. section 6.1.1 section 10.3
Podman builds the namespace from the user’s current UID/GID and subordinate ranges in /etc/subuid and /etc/subgid. Each entry contains a login name or numeric ID, a starting subordinate ID, and a count. Ranges should be unique per user and must not overlap system IDs; Podman does not verify this automatically. section 5.4 section 6.2
Use the namespace mapping to understand common rootless Podman behavior:
- Root inside a container maps to the invoking user or a subordinate host UID, so container root is not host root. section 10.3
- A rootless user normally receives one shared user namespace for that user’s containers; Podman keeps it alive with a podman pause process. section 6.2
- Changing subordinate-ID files does not immediately alter an existing namespace; podman system migrate recreates the pause process and applies the changes. section 5.4
- Capabilities inside the namespace affect mapped UIDs, GIDs, and associated namespaces rather than granting equivalent capabilities on the host. section 10.3.2
Inspecting a rootless mapping
Run `podman unshare cat /proc/self/uid_map` to inspect the namespace. A mapping such as `0 3267 1` and `1 100000 65536` makes container UID 0 map to host UID 3267 and container UIDs 1–65536 map into the subordinate range beginning at 100000. `podman unshare` also lets you observe how ownership changes inside the namespace appear as subordinate numeric owners on the host. section 6.1.1
Allocating a separate namespace per container
Configure a sufficiently large subordinate range, then run `podman run --userns=auto ubi8 cat /proc/self/uid_map`. Podman allocates a non-overlapping range, using 1024 UIDs by default, and reclaims the range when a removed container is recreated. Override the allocation with `--userns=auto:size=5000` when the image needs more IDs. section 10.3.1
Separate namespaces reduce UID-based attacks between containers, but rootless allocation is limited by the user’s subordinate range. With the default 65,536 IDs, automatic allocation can support at most 64 containers using 1024-ID ranges, and ordinary mappings may overlap automatic ones. section 10.3.3 section 10.3.1
Volumes add another ownership boundary. The `:U` volume option changes source ownership to match the container’s primary UID, while `:idmap` presents remapped ownership without changing on-disk ownership. Idmapped mounts require filesystem and runtime support and are described as a newer feature. section 10.3.4
Use the UID mapping figure to trace how host and container identifiers correspond across a rootless namespace. section 5.4
