A writable bind mount of a system or home directory (/etc, /root, /home, /var/run, /proc, /sys, ~/.ssh or / itself) lets a compromised container change host configuration or read credentials. The explainer flags these as high when the mount is not read-only. The fix is to mount only the specific file or subdirectory the service needs, and add :ro when it only reads.
What the free Docker Compose explainer reports on the risky example below.
Why it matters
A bind mount is the host's own directory, not a copy. Whatever the container writes there changes the host: a user added to /etc/passwd, a cron entry, a key appended to ~/.ssh/authorized_keys.
Reading is risky too. Home directories hold SSH keys, cloud credentials and shell history, and the container process often runs as root, so ordinary file permissions do not stop it.
These mounts are usually added for one file (a timezone, a CA bundle, a config) and mount the whole directory because it was quicker.
services:
app:
image: example/app:1.4.2
volumes:
# Only the one file the service reads, read-only
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
mem_limit: 512m
How to fix it
Find which file or subdirectory the service actually uses and mount only that path.
Add :ro (or read_only: true in the long syntax) when the service only reads it.
For data the service writes, use a named volume or a dedicated directory such as ./data, not a system path.
When it's acceptable
A read-only mount of a single well-known file, such as /etc/localtime; the explainer does not flag read-only mounts.
Host monitoring agents that document a need to read /proc or /sys. Mount them read-only and check the vendor's documentation for the narrowest paths.
Check your own docker-compose.yml
The risky example is loaded below. Paste your own file to check it for this and every other Docker Compose rule. It runs in your browser; nothing is uploaded.
Limits memory to 512m. The container is killed if it exceeds this.
Questions
Is it safe to mount /etc into a Docker container?
Not writable. A container that can write the host's /etc can change users, services and scheduled jobs on the host. Mount the single file you need with :ro instead.
Does :ro make a bind mount safe?
It stops the container from changing the host files, which removes the most direct way to tamper with the host. The container can still read them, so avoid mounting directories that hold keys or credentials at all.
Which host paths does the explainer treat as sensitive?
/, /etc, /root, /home, /var/run, /proc, /sys and ~/.ssh, plus anything under them, when the bind mount is writable. Mounts that expose the Docker socket are reported by a separate, critical rule.