PID-namespace separation -- why is /proc:/proc mounted by default?

[laur89]

Per this issue regarding inner container having visibility of the outer process tree, u/giuseppe points out:

The mount for proc is specified in the /home/podman/.config/containers/containers.conf file in the podman image.

This is correct:

$ podman run --rm quay.io/podman/stable cat /home/podman/.config/containers/containers.conf
[containers]
volumes = [
	"/proc:/proc",
]
default_sysctls = []

Why is this default there, i.e. why is /proc mounted from the parent/outer container?

[yhay81]

It is a workaround for a limitation of rootless Podman nested inside a container, not a general recommendation to share the host's /proc.

The outer container's default masked /proc does not give the nested rootless engine enough privilege/visibility to mount a fresh procfs for an inner container. At the same time, the OCI runtime must have either a PID namespace or cgroups to track the inner container's processes; cgroups are not available in this setup, so Podman creates a PID namespace. The image's /proc:/proc default lets the nested container start without requiring the outer container to expose a fully unmasked procfs.

The tradeoff is exactly what you observed: the procfs superblock came from the outer PID namespace even though the inner container has a new PID namespace. Therefore /proc and the process IDs seen by the inner process can disagree, and the outer process tree is visible through that mount.

If you need a namespace-correct /proc, override the image's user config and allow the nested engine to mount a fresh procfs:

podman run --rm \
  --env CONTAINERS_CONF=/etc/containers/containers.conf \
  --security-opt=unmask=/proc/* \
  --security-opt label=disable \
  --user podman \
  --device /dev/fuse \
  quay.io/podman/stable \
  podman run --rm alpine ps

CONTAINERS_CONF selects the system config, which does not contain the image's /proc:/proc volume. unmask=/proc/* on the outer container is what permits nested Podman to create the fresh proc mount. This is the workaround the Podman contributor gave in #19440.

There is a security tradeoff: the Podman container gets a less-restricted view of the outer /proc, so use that only for a trusted nested-engine container. If inner workloads do not need a namespace-consistent /proc, keeping the image default avoids granting that extra access.