pid: host puts the container in the host's process namespace instead of its own. Processes inside can list every process on the machine with its command line, and with enough privileges send signals to them or inspect their memory. The explainer marks it critical. Remove it unless the service is a host-level debugging or monitoring tool you trust.
openrouting — compose explainer
$ explain docker-compose.yml! app shares the host PID namespace criticalline 4fix: see below$
What the free Docker Compose explainer reports on the risky example below.
Why it matters
A normal container only sees its own processes. With `pid: host` it sees everything on the host, including command lines, which often carry configuration and sometimes secrets passed as arguments.
Root in the container keeps the default capability to send signals, so it can stop host processes. With `SYS_PTRACE` added, it can also attach to them and read their memory.
Combined with other loosened settings, such as privileged mode or `cap_add: [SYS_ADMIN]`, a shared PID namespace makes it straightforward to enter the namespaces of a host process and run commands as that process.
services:
app:
image: example/app:1.4.2
# No pid key: the container gets its own process namespace
restart: unless-stopped
mem_limit: 512m
How to fix it
Remove pid: host.
If two services need to see each other's processes, share between them with pid: "service:<name>" instead of the host namespace.
Run host-level debugging tools only when needed, with docker run on the host, rather than leaving them in a long-running stack.
When it's acceptable
Trusted host monitoring or profiling agents that are designed to observe every process on the machine.
A short debugging session on your own machine, removed when you are done.
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.