Question
Does rootless Podman share one user namespace across containers in a pod?
Ari Byte
0 reputation · 13 Apr 2024, 16:25 UTC
56.8K views1
Loading…
0 reputation · 13 Apr 2024, 16:25 UTC
Goal: determine whether rootless Podman containers started in the same pod receive separate user namespaces or share a single namespace, because UID mapping controls file ownership and access permissions.
Podman's rootless mode depends on user namespaces, but documentation does not consistently specify whether each container in a pod receives its own UID range or whether the pod shares one mapping. Behavior may vary by Podman release and by launch context, such as a systemd user session versus a plain shell.
Does rootless Podman allocate a distinct user namespace for every container in a pod by default? When namespaces are shared, how are overlapping UID mappings resolved? Is this behavior consistent across recent Podman releases?
When you start containers with podman run --pod=<name> in rootless mode, they do not each receive a separate user namespace. Instead, the pod itself owns a single user namespace, and every container joined to that pod inherits the same UID-to-host-UID mapping. UID 0 inside one container is therefore the same host user as UID 0 inside another container in the same pod.
Within a shared pod namespace there are no overlapping mappings to resolve. All containers see the identical UID range established when the pod was created—sometimes explicitly with --userns=keep-id, sometimes via an automatically allocated subordinate range. File ownership on shared volumes is consistent: a file created by UID 1000 in container A appears as UID 1000 in container B.
The situation changes only when you explicitly override the namespace on an individual container. Passing --userns to podman run for a container already attached to a pod gives that container its own independent user namespace. You then have two namespaces with potentially different UID ranges, and the same host UID can map to different container UIDs, breaking volume-based file ownership expectations.
Podman 4.x standardized this behavior: pod member containers share the pod's user namespace unless overridden. Earlier 3.x releases generally behaved the same way, but exact mapping details varied more across microversions. For production systems, treat the sharing behavior as stable but verify the actual UID map on your specific binary.
podmanpodman pod inspect <pod-name> | grep -i usernspodman exec <container> cat /proc/self/uid_mapIf you are using --userns=keep-id, the map will show your login UID mapped to the same UID inside every container. If Podman auto-allocated a range, you will see a block of subordinate UIDs instead.
Do you intend to pass --userns to any individual podman run command after the pod is created? If so, the shared-namespace assumption no longer holds for that container, and you should avoid sharing volumes between it and the rest of the pod unless you remap ownership explicitly.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 13 Apr 2024, 21:53 UTC
To practically verify that containers in a pod are sharing the same user namespace, you can inspect the kernel's mapping files directly. While podman pod inspect provides the configuration, the runtime reality is stored in the proc filesystem.
Run the following command in two different containers within the same pod:
cat /proc/self/uid_mapIn a standard rootless Podman 4.x setup, the output should be identical for both containers. This confirms they are utilizing the same mapping of container UIDs to the host's subordinate UID range (defined in /etc/subuid). If the strings differ, it indicates that a container-specific override—such as --userns—has been applied, effectively isolating that container's identity from the rest of the pod.