User Namespaces

User Namespaces and UID Mapping

A user namespace maps user and group IDs inside it to different IDs outside, so a process can be root inside while the kernel treats it as an ordinary user on the host. It is the one namespace an unprivileged user can create:

Being root in a user namespace, and nowhere elseShell
unshare --user --map-root-user sh -c 'id; cat /proc/self/uid_map; touch /etc/l3-test'
grep '^dev:' /etc/subuid
Output
uid=0(root) gid=0(root) groups=0(root),65534(nogroup),65534(nogroup),65534(nogroup)
         0       1000          1
touch: cannot touch '/etc/l3-test': Permission denied
dev:100000:65536

uid_map reads "inside UID 0 is outside UID 1000, for 1 ID", so this root is really dev and cannot write to /etc; unmapped groups appear as nogroup. A full container needs more IDs, which /etc/subuid grants: dev may use 65,536 host UIDs from 100000. Rootless Docker 514 (Rootless Mode) maps container root to dev and the rest into that range. Rootful Docker, as lsns showed, leaves containers in the host's user namespace, so container root is host root, held back by dropped capabilities and seccomp (and AppArmor 454,622 where enabled). "userns-remap": "default" in daemon.json changes that, at some cost in bind-mount compatibility.