can't bind privileged ports using normal rootless approaches (Debian stable / podman 5.4.2)

[davison]

Aware that 5.4.2 is not the latest, but I use Debian stable for some production workloads and that's what's currently in the repos :)

This may be an OS issue or related tools, not podman, I don't know, but asking here for some guidance as to what could be the cause.

Summary of Issue

On Debian 13 (Trixie) with Podman v5.4.2, rootless containers defined via Quadlets cannot bind to privileged ports using the standard secure methods (setcap or ping_group_range). The only successful method is to lower the system-wide net.ipv4.ip_unprivileged_port_start value.

Steps to Reproduce

1. Goal: Bind a rootless container to host port 80 using a Quadlet .container file.
2. Attempt 1: Added AddCapability=NET_BIND_SERVICE.
   • Result: Failed. The default pasta network driver, running as a non-root user, could not bind to the host port.
3. Attempt 2: Switched the network driver by adding Network=slirp4netns.
   • Result: Failed. The rootlessport helper process errored with bind: permission denied, indicating it lacked permission on the host.
4. Attempt 3: Granted file capabilities to the helper: sudo setcap 'cap_net_bind_service=+ep' /usr/libexec/podman/rootlessport.
   • Result: Failed with the identical permission denied error from rootlessport.
5. Attempt 4: Reverted setcap and used the alternative sysctl method: sudo sysctl -w net.ipv4.ping_group_range="0 0".
   • Result: Failed with the identical permission denied error from rootlessport. No AppArmor denials were logged.
6. Workaround: Used the global sysctl setting: sudo sysctl -w net.ipv4.ip_unprivileged_port_start=80.
   • Result: Success. The container started and bound to port 80 correctly.

Conclusion

The expected behavior is that either setcap on rootlessport or setting ping_group_range should allow rootless Podman to bind to privileged ports. As neither method worked, it suggests a potential regression or incompatibility within Podman or its interaction with the kernel/security policies on Debian 13.

[eriksjolund]

Regarding setcap see discussion thread

Another alternative: Using socket activation in a systemd system service with User= systemd directive.
This alternative is not officially supported by the podman project (in other words, use at your own risk). For details, see https://github.com/eriksjolund/podman-networking-docs?tab=readme-ov-file#socket-activation-systemd-system-service-with-user
If your software does not support socket activation and you would like to experiment even more you could check out libsdsock. For details, see https://github.com/eriksjolund/podman-networking-docs?tab=readme-ov-file#add-socket-activation-support-by-preloading-libsdsock-with-ld_preload

Update: I modified the link so that it now points to the discussion thread.

[davison]

awesome - thanks for all the pointers @eriksjolund

[sbrivio-rh]

Just to be clear: the consideration from #24022 (reply in thread) applies to rootlessport and pasta in the same way, as they are both started by Podman in the container's user namespace, so they can't gain CAP_NET_BIND_SERVICE "back" in the initial / parent / "host" namespace. I was wrong in the comment above that one.

The expected behavior is that either setcap on rootlessport or setting ping_group_range should allow rootless Podman to bind to privileged ports. As neither method worked, it suggests a potential regression or incompatibility within Podman or its interaction with the kernel/security policies on Debian 13.

On the other hand, I guess it never worked, so it doesn't sound like a regression. It also has little to do with Debian 13 or AppArmor specifically, it should be the same with any distribution or Linux Security Module.

By the way, ping_group_range is unrelated to the problem at hand. That's to allow unprivileged / rootless containers to ping other nodes. That part should work as expected.