You are choosing the container runtime standard for a fleet of shared Linux build hosts and edge devices. Compare a rootful Docker daemon, rootless Docker, and Podman's daemonless model, and explain how you would decide.
answer
- axis = privileged shared management plane
- rootful: everything works, socket is root
- rootless: same daemon scoped to a user, N caches
- podman: fork/exec + conmon, audit loginuid kept
- Quadlet systemd units for edge
basics
~20 sRootful Docker centralizes root in one long-lived daemon and socket. Rootless Docker keeps the daemon but confines it to a user. Podman drops the daemon entirely: containers are children of the invoking user, so identity and audit follow the human. Decide on isolation, auditability and feature needs.
solid answer
~50 sThree points on one axis — how much privileged, shared, long-lived machinery sits between a user and a container. **Rootful Docker**: a root daemon plus a socket that is a root grant. Every feature works; blast radius is the whole host; actions are attributed to the daemon. **Rootless Docker**: the same architecture, per user, inside a user namespace. Most of the isolation win with unchanged tooling, but you pay userspace networking, no privileged ports, no image sharing between users, and feature gaps. **Podman**: no daemon — `podman run` forks the container under conmon as the invoking user, so the audit login uid survives, there is no shared socket, and containers become ordinary systemd units (Quadlet). Best fit for multi-tenant hosts and edge devices with systemd supervision. I would decide on multi-tenancy and audit requirements, whether privileged features are genuinely needed, and ecosystem coupling — Compose, Testcontainers and buildx assume a Docker socket, and Podman's compatibility socket covers most but not all of it.
code
bash · 15 linespodman run -d --name api docker.io/library/nginx:alpine
ps -o pid,ppid,user,cmd -C conmon
# conmon is a child of the invoking user's session, not of a root daemon
# Quadlet: containers as first-class systemd units
cat ~/.config/containers/systemd/api.container
# [Container]
# Image=docker.io/library/nginx:alpine
# PublishPort=8080:80
# [Service]
# Restart=always
# [Install]
# WantedBy=default.target
systemctl --user daemon-reload && systemctl --user start apigo deeper
Know that Podman runs containers without a background daemon and defaults to rootless, whereas Docker has a daemon.
Contrast the process models and name concrete consequences: no root socket, systemd supervision, shared limitations of rootless operation.
Argue the operational differences — audit attribution, restart supervision, compatibility socket — and identify which workloads still need rootful.
Set policy by host role, quantify migration and ecosystem cost, and separate developer-host runtime choice from production orchestration runtimes.
## The real dimension of comparison All three run OCI containers on the same kernel primitives — namespaces, cgroups, seccomp. What differs is the *management plane*: whether a privileged, shared, long-lived process brokers container operations. ## Rootful Docker One root daemon owns all containers, images and networks. Advantages: everything works — privileged ports, device passthrough, swarm overlay networks, native overlay storage, a shared image cache across users, and the ecosystem's default assumption. Costs: the socket is a root grant, so anyone allowed to use containers is effectively an administrator; a daemon bug or supply-chain compromise of the daemon is a host compromise; containers are children of the daemon rather than of the requesting session, so systemd cannot supervise them directly and audit records do not attribute work to a human; and daemon restarts are a host-wide event. ## Rootless Docker The same design, scoped down: each user runs their own `dockerd` inside a user namespace, with private storage, its own socket and no host privileges. The compromise ceiling drops to that one account, which is a large improvement on multi-user hosts. But it is still a daemon per user — N image stores, N build caches, N background processes — and you inherit the limitation list: no ports under 1024 without a sysctl or capability grant, userspace networking with lower throughput, resource limits only with cgroup v2 delegation, restricted devices and mounts, no swarm overlay, and a daemon that dies at logout without lingering. Its strongest argument is continuity: existing Docker CLI habits, Compose files and CI images keep working. ## Podman Podman removes the daemon. The CLI itself sets up namespaces and execs the runtime (`crun`/`runc`), with a small `conmon` process per container holding the tty and exit status. Consequences that matter at fleet scale: - **Identity and audit.** The container is a descendant of the user's session, so the kernel audit subsystem keeps the real login uid. "Who ran this container?" has an answer. - **No shared root socket.** There is no `docker` group equivalence to govern. - **systemd-native.** Quadlet unit files describe containers as first-class services with normal dependency ordering, restart policy and journald integration — excellent on edge devices where systemd is the supervisor anyway. - **Rootless by default**, with the same user-namespace mechanics and the same low-port and networking constraints. - **Pods** group containers with a shared network namespace, which maps neatly onto Kubernetes-shaped thinking without running an orchestrator. Costs: a smaller ecosystem of assumptions. Tools that hardcode `/var/run/docker.sock` need Podman's compatibility socket; Testcontainers, buildx features and some Compose behaviors need verification; Docker Desktop workflows and Swarm are not equivalents; and your team pays a learning tax on a second CLI dialect. ## Deciding I would set defaults by host role rather than picking one winner. **Shared multi-tenant build hosts:** daemonless or rootless, because audit and blast-radius arguments dominate and the throughput penalty is usually irrelevant next to compile time. **Edge devices:** Podman with Quadlet units, because there is no operator on site and systemd supervision with automatic restart and journald beats a daemon plus restart policies. **Single-purpose hosts that genuinely need privileged features** — device passthrough, low ports, overlay networking — keep rootful, but treat login on those hosts as an administrative grant and keep them out of the shared pool. Note also that Kubernetes nodes are largely out of scope for this decision: they run containerd or CRI-O under the kubelet, so developer-host runtime choice is decoupled from production orchestration, which frees you to optimize hosts for isolation rather than parity with prod. Finally, plan the migration cost honestly: pipeline images, Compose files, socket-dependent tooling and documentation all carry Docker assumptions. A standard nobody can adopt is worse than a slightly weaker one everyone actually runs.
- If Podman is daemonless, how do tools that expect a Docker socket still work?Podman ships a service exposing a Docker-compatible REST API on a socket, usually socket-activated by systemd for the user. Tools pointed at it via DOCKER_HOST work for most operations. It is a compatibility layer, not an identical implementation, so build features, Compose edge cases and Testcontainers behaviors need verification rather than assumption.
- Does choosing Podman on developer machines create a parity problem with a Kubernetes production environment?Less than people expect: Kubernetes nodes run containerd or CRI-O, not Docker, so neither Docker nor Podman on a laptop matches production exactly. What must match is the image and its OCI runtime behavior, and both produce standard OCI images. The real parity risks are build-time differences and tooling assumptions, handled by building images in CI the same way for everyone.
Rootful Docker is a building superintendent with a master key doing every job for everyone; Podman hands each tenant their own tools and lets the building log who did what.
saying these in an interview costs you the question
- Framing it as 'Podman is more secure' without naming the daemon and audit-attribution mechanisms
- Ignoring migration cost — socket-dependent tooling, Compose files, CI images
- Assuming rootless Docker and Podman have different low-port or networking constraints; they share most of them
- Claiming a daemonless runtime on laptops breaks Kubernetes parity, when nodes run containerd or CRI-O anyway