bind mount path traversal depends on subuid mapping, not just DAC permissions

[Barnoux]

Summary

While investigating why rootless Podman could bind mount /etc/letsencrypt/ (owned by certbot:certbot, mode 750) without the running user having group membership, i discovered a "weird" behavior: whether a bind mount
source path can be traversed depends on whether the parent directory's UID falls within the user's subuid or range, not just standard DAC permissions.

Environment

Client: Podman Engine
Version: 5.4.2
API Version: 5.4.2
Go Version: go1.24.4
Built: Sun Dec 21 17:42:12 2025
Build Origin: Debian
OS/Arch: linux/arm64

Rootless, systemd quadlet (user session)
/etc/subuid: barnoux:100000:65536

Reproduction

# subuid range: 100000:65536

# FAILS — UID 0 not mapped
sudo mkdir -p /tmp/test_root/child && sudo chmod 700 /tmp/test_root
podman run --rm -v /tmp/test_root/child:/mnt alpine echo ok
# Error: statfs /tmp/test_root/child: permission denied

# FAILS — UID 300000 outside range
sudo mkdir -p /tmp/test_out/child
sudo chown 300000:300000 /tmp/test_out && sudo chmod 700 /tmp/test_out
podman run --rm -v /tmp/test_out/child:/mnt alpine echo ok
# Error: statfs /tmp/test_out/child: permission denied

# SUCCEEDS — UID 100999 inside range (doesn't need to be a real user)
sudo mkdir -p /tmp/test_in/child
sudo chown 100999:100999 /tmp/test_in && sudo chmod 700 /tmp/test_in
podman run --rm -v /tmp/test_in/child:/mnt alpine echo ok
# ok

What i thought at the beginning

At first i was thinking that you could bind mount a volume if you have execute access on the parent folder.

Question

Is the behavior that i identified is intentional and expected? If so, it could be great to have some explanation, my brain hurts.

[jmrplens]

Yes, that's expected, and it's the kernel's user namespace rules rather than anything podman decides on its own.

I ran your three cases on Debian with podman 5.4.2 and a subuid range like yours (100000:65536) and got the same result: the parents owned by 0 and by 300000 fail with statfs ...: permission denied, the one owned by 100999 mounts fine.

What explains it is how those directories look from inside the namespace. podman unshare ls -ldn on the three parents gives:

/tmp/t_in    uid=1000   gid=1000     (host owner 100999)
/tmp/t_out   uid=65534  gid=65534    (host owner 300000)
/tmp/t_root  uid=65534  gid=65534    (host owner 0)

Inside the namespace you are root, but your capabilities only cover ids that are mapped into it. An owner outside your subuid range shows up as the overflow id, 65534 (user_namespaces(7) has a section on unmapped ids), and against that the 700 on the parent is enforced like for any unprivileged user. An owner inside the range is mapped, DAC override applies, and the 700 does not stop you. The check the kernel does is whether the owner is mapped in your namespace, not whether you could traverse the path on the host.

Your /etc/letsencrypt case is the same thing. If certbot's uid happens to sit inside your subuid range you can traverse it whatever the mode says. That is really about how ranges get assigned: a subuid range that overlaps real service accounts gives that user DAC override on those files inside any namespace they create. It's the reason the defaults start at 100000, and hosts that have service uids up in that space are where this bites.

For what it's worth, --userns=keep-id does not change any of this. It changes which uid you are inside the container, not which host ids the namespace maps, so the three cases behave the same with it.