Explain what Docker's rootless mode changes about how the daemon and its containers run, including the role of `/etc/subuid` and the `newuidmap` helper, and what ownership a host file gets when a rootless container writes it as its own root user.

## The problem rootless mode solves Classic Docker has a root-owned daemon: a long-lived process with full privileges that builds images, mounts filesystems and configures networking on behalf of anyone who can reach its socket. A bug in it, or an escape from a container it launched, is an immediate host compromise. Rootless mode removes the root process from the picture. ## User namespaces and subordinate id ranges A **user namespace** is a kernel mechanism giving a process its own mapping from ids inside the namespace to ids outside. An unprivileged user may create one and be uid 0 within it with a full capability set — but those capabilities apply only to resources owned by the namespace, so they do not translate into power over the host. A namespace needs a *mapping*. Mapping only your own uid gives a single id, which is not enough to run a distro image that expects root plus service accounts. So Linux provides **subordinate id ranges**: `/etc/subuid` and `/etc/subgid` contain lines such as `alice:100000:65536`, meaning alice may use host uids 100000–165535 inside namespaces she creates. Writing that multi-entry map into `/proc/<pid>/uid_map` is privileged, which is where **`newuidmap`** and **`newgidmap`** (from the `uidmap` package, installed setuid-root or with file capabilities) come in: Docker's RootlessKit execs them, they validate the request against `/etc/subuid`/`/etc/subgid`, and write the map. These two small helpers are the only privileged code involved. ## What the mapping means in practice With the range above, container uid 0 is host uid 100000, container uid 1000 is host uid 100999, and so on. Consequences worth stating explicitly: - A file written to a bind mount by container root appears on the host owned by 100000 (often displayed as a bare number, since no such user exists in `/etc/passwd`). - To let a rootless container write into an existing host directory you must `chown` it into the mapped range, or use a mapping that passes your own uid straight through (Podman spells this `--userns=keep-id`). - The container can never read a host file its owning user could not already read, because the effective host identity always sits inside that subordinate range. ## The rest of the rootless stack Rootless Docker also needs privileged-looking operations for networking and mounts, and gets them from userspace components: **RootlessKit** creates the namespaces and handles port forwarding, **slirp4netns** (or pasta) provides a userspace TCP/IP stack for outbound connectivity, and storage uses native `overlay2` on modern kernels or **fuse-overlayfs** where unprivileged overlay mounts are unsupported. State lives under `~/.local/share/docker` and the socket at `$XDG_RUNTIME_DIR/docker.sock`, so each user has an independent daemon, independent images and no shared cache. ## What it protects and what it does not It collapses the blast radius of daemon bugs and container escapes to one unprivileged account. It does not protect you *within* that account — anything the user can read, a compromised container can read, including their SSH keys. It does not stop kernel exploits that break out of the user namespace itself (user namespaces have historically widened kernel attack surface, which is why some hardened distros gate them). And it is orthogonal to the application's own exposure. Rootless mode is a containment measure, not an application security control.