rootless container leaks information

[tobwen]

Before posting a bug, I'd like to discuss whether this behaviour is expected or not.

What am I doing?

Running a rootless podman in a root environment and handling down /dev/fuse to a container with Alpine:

podman run --user podman --device /dev/fuse -it quay.io/podman/stable \
podman run --cap-add=sys_admin --cap-add mknod --device=/dev/fuse -it --rm alpine:edge sh -c "apk add pstree && pstree -w"

What did I notice?

Lots of information from the the first container is leaked into the second one. Also, catatonit isn't PID 1, but dangling around.

# pstree -w
-+= 00001 root podman run --cap-add=sys_admin --cap-add mknod --device=/dev/fuse -it --rm alpine:edge sh -c apk update && apk add pstree && pstree -w
 |-+= 00058 root /usr/bin/conmon --api-version 1 -c 0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e -u 0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e -r /usr/bin/crun -b /home/podman/.local/share/containers/storage/overlay-containers/0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e/userdata -p /tmp/podman-run-1000/containers/overlay-containers/0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e/userdata/pidfile -n gallant_mahavira --exit-dir /tmp/podman-run-1000/libpod/tmp/exits --full-attach -l k8s-file:/home/podman/.local/share/containers/storage/overlay-containers/0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e/userdata/ctr.log --log-level warning --runtime-arg --log-format=json --runtime-arg --log --runtime-arg=/tmp/podman-run-1000/containers/overlay-containers/0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e/userdata/oci-log --runtime-arg --cgroup-manager --runtime-arg disabled -t --conmon-pidfile /tmp/podman-run-1000/containers/overlay-containers/0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/podman/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /tmp/podman-run-1000/containers --exit-command-arg --log-level --exit-command-arg warning --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /tmp/podman-run-1000/libpod/tmp --exit-command-arg --network-config-dir --exit-command-arg  --exit-command-arg --network-backend --exit-command-arg netavark --exit-command-arg --volumepath --exit-command-arg /home/podman/.local/share/containers/storage/volumes --exit-command-arg --runtime --exit-command-arg crun --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --events-backend --exit-command-arg file --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --rm --exit-command-arg 0a1fc133b7dfe7c11e6af72e9d79ae50a6006313a40c9df9fb8c9b8e9d677c4e
 | \--= 00060 root pstree -w
 |--- 00022 root podman run --cap-add=sys_admin --cap-add mknod --device=/dev/fuse -it --rm alpine:edge sh -c apk update && apk add pstree && pstree -w
 |--- 00021 root catatonit -P
 \--- 00017 root (podman)

Question

Is this behaviour expected? Is it a problem? Can I do it better? Is there some namespace-mixing happening?

Environment

Latest stable Debian with Kernel 5.19 on AMD64

# conmon --version
conmon version 2.1.4
commit: 1fe1605205f909a33961e06af7bbdb085c062fa4

# crun --version
crun version UNKNOWN
commit: 515912848d18bdc29bc87a9d6164fd0fdad6f2a6
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL

# podman --version
podman version 4.3.0-dev

[Luap99]

Check the containers.conf in the quay.io/podman/stable image. It uses many host namespace settings by default so yes the leak is expected.

[Luap99]

this is the containers.conf file: https://github.com/containers/podman/blob/main/contrib/podmanimage/stable/containers.conf

[tobwen]

Check the containers.conf in the quay.io/podman/stable image.

I thought this might be the actual problem:

/home/podman/.config/containers/containers.conf
[containers]
volumes = [
        "/proc:/proc",
]

It uses many host namespace settings by default so yes the leak is expected.

Thanks, I'll try to play with it. Is this "leak" bad in terms of isolation and security?