What does `docker run --read-only` actually make read-only, and why do most containers then need `--tmpfs`?

## What the flag actually changes A container normally gets a thin writable layer stacked on top of the image's read-only layers by the storage driver (with overlay2, that is the `upperdir`). Everything the process creates or modifies at runtime lands in that layer and is discarded when the container is removed. `docker run --read-only` still gives the container that layer, but Docker mounts the assembled root filesystem read-only, so a write to any path that came from the image fails immediately with the kernel error `EROFS` — surfaced as `Read-only file system` in strace and shell output, and as messages like `EROFS: read-only file system, open '/app/.cache/entry.json'` from a language runtime. The purpose is not disk hygiene, it is blast radius. Once the root filesystem is read-only, an attacker who reaches code execution inside the container cannot drop a payload next to the application, cannot overwrite a JavaScript file or configuration the runtime will load on the next request, cannot install a package, and cannot leave anything behind that survives a restart. A whole family of exploitation steps that assume "write a file, then execute it" turns into an error at the first step. It also makes the container genuinely immutable: the only code that can run is what the image shipped, plus whatever you deliberately made writable. ## What stays writable The flag applies to the root filesystem only. Anything mounted into the container is a separate mount with its own flags: - **Named volumes** — `-v scorer-data:/var/lib/scorer` is writable under `--read-only`. - **Bind mounts** — writable unless you append `:ro`. - **tmpfs mounts** — writable by definition. So `--read-only` is not "nothing in this container can be written"; it is "nothing can be written except the paths I granted". If you want a mounted path read-only too, say so explicitly (`:ro`, or `readonly` in `--mount` syntax). ## Why tmpfs is nearly always required Very few programs write nothing. The paths that break first are boringly predictable: - `/tmp` — upload staging, temp files, unix sockets, JVM `hsperfdata`, extracted jars. - `/run` or `/var/run` — pid files and unix sockets (an nginx-style server writes `nginx.pid` here before it ever serves a request). - Package-manager and language caches — an npm or pip cache directory, `__pycache__`, a compiled-template directory. - `/var/log/...` for anything that logs to a file rather than to stdout. `--tmpfs /tmp:rw,noexec,nosuid,size=48m` mounts a RAM-backed filesystem there. Properties worth knowing: it starts empty on every run, disappears when the container stops, is private to that container (two replicas do not share it), and its pages are charged to the container's memory accounting — which is why an unsized tmpfs is a real hazard. A runaway temp file can consume host RAM or push the container into an OOM kill. Set `size=` on every tmpfs mount, even generously; the number is a ceiling, not a reservation. The `noexec` and `nosuid` options matter as much as the size. A writable `/tmp` is exactly where an attacker would drop a payload; `noexec` means the kernel refuses to execute it from that mount, and `nosuid` means a setuid bit on a file written there is ignored. Adding a tmpfs without those options gives back a good part of what `--read-only` just took away. ## Deciding what each path deserves When a path fails under `--read-only`, there are three good answers and one bad one: 1. **Ephemeral scratch** — mount a sized tmpfs. 2. **State that must survive a restart** — mount a named volume; then you have also documented, in the run command, exactly what the service's durable state is. 3. **Something written once at startup that never changes** — a downloaded model file, a generated asset bundle, a compiled template cache. Move it into the image at build time. That removes the write, speeds up start, and makes every replica byte-identical. 4. **The bad answer** — drop `--read-only`, or bind-mount something writable over a large part of the tree. ## Operating with it `docker inspect -f '{{.HostConfig.ReadonlyRootfs}}' <container>` confirms the setting. In Compose the same controls are `read_only: true` plus a `tmpfs:` list. Finally, keep the claim honest in an interview: a read-only root filesystem restricts *writes*. It does not restrict syscalls, capabilities, devices or the network, and it does not stop an attacker executing a shell, a package manager or an interpreter that the image already contains. It composes with a minimal base image and the rest of the runtime confinement flags; on its own it is one strong control, not a sandbox.