Which container-escape scenarios does daemon-level user-namespace remapping actually mitigate, and which Docker features stop working once it is enabled?

## What the boundary actually is Remapping changes one thing: the credentials the kernel evaluates when a container process touches a resource *outside* its namespaces. Inside the namespace, root is still root. So the honest framing is "in-container root loses authority over host-owned things", not "the container is now safe". ## Real mitigations - **Bind-mount abuse.** The classic bad day is a container with `/etc` or `/var/run` mounted read-write, or an operator who mounts a host path for convenience. Un-remapped, container root rewrites those files freely; remapped, the writes are refused unless the host path was deliberately re-owned into the mapped range. - **Ownership games.** `chown`, setuid bits and similar tricks are confined to IDs inside the mapped block, so a container cannot manufacture a setuid-root binary that means anything on the host. - **Device and kernel operations.** Loading modules, most raw device access, changing host time, and other operations on non-namespaced state require real UID 0 with the right capability in the *initial* user namespace; a mapped root does not have it, even though `capsh` inside shows a full set. - **Escape landing zone.** A process that escapes the mount or PID namespace but remains in the user namespace is unprivileged on the host — a materially smaller second stage. ## What it does not touch - **Kernel vulnerabilities.** A bug that grants UID 0 from any UID makes the mapping irrelevant. Worse, user namespaces themselves are a well-known source of privilege-escalation CVEs, so enabling them is not a free security win — some hardened distributions restrict unprivileged namespace creation for exactly that reason. - **The daemon socket.** A container able to talk to the daemon socket can ask the daemon to start a container that opts out of the mapping. Remapping is orthogonal to that risk. - **Container-to-container.** One shared mapping means every container's root is the same host UID. Two containers on a shared volume have identical authority over each other's files. Per-tenant separation needs per-workload UIDs on top, or a different isolation technology. - **The daemon's own surface.** The daemon still runs as real root; only containers are shifted. ## Incompatibilities and cost Docker documents concrete restrictions. A container cannot share the host PID or network namespace while remapped, and privileged mode is not compatible — such containers must be started with `--userns=host`, which silently returns them to the old model, so audit for that flag. External storage or volume drivers that write files with fixed UIDs produce files the container cannot read. Everyday flags such as `--read-only` are unaffected. Operationally: the daemon moves its data root to `/var/lib/docker/<uid>.<gid>/`, so images are re-pulled and disk usage can double if you keep both trees; every existing bind mount needs re-owning; and troubleshooting gets a new failure mode engineers must learn to recognise (files showing as `nobody`). ## How to position it Remapping is most valuable when you must run legacy images that insist on being root, on hosts that are not per-workload disposable. If your images already run as an unprivileged `USER` and your containers drop capabilities and mount nothing sensitive, the marginal gain is small and the friction is real — in that situation the stronger next step is usually reducing the daemon's own privilege or tightening run-time policy, not remapping alone.