Why rootless container cannot listen to port 80, even with cap_net_bind_service in bounding set ?

[worming004]

From this Containerfile:

FROM ubuntu:latest

RUN apt update
RUN apt install netcat -y
RUN apt install curl -y
RUN apt install libcap2-bin -y

RUN adduser --disabled-password --gecos '' appuser
USER appuser

EXPOSE 80

ENTRYPOINT ["/bin/bash"]

The command podman build -t tmp . build an image that will run by default a non root user. Then starting container with podman run --rm -it tmp then running nc -l -p 80 fail as expected.

nc: Permission denied

But, I am not sure why. I was expecting that cap_net_bind_service would be absent and could explain why. But this is not the case, the capability is present.

From container:

appuser@d95227099e7f:/$ capsh --print
Current: =
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_sys_chroot,cap_setfcap
Ambient set =
Current IAB: !cap_dac_read_search,!cap_linux_immutable,!cap_net_broadcast,!cap_net_admin,!cap_net_raw,!cap_ipc_lock,!cap_ipc_owner,!cap_sys_module,!cap_sys_rawio,!cap_sys_ptrace,!cap_sys_pacct,!cap_sys_admin,!cap_sys_boot,!cap_sys_nice,!cap_sys_resource,!cap_sys_time,!cap_sys_tty_config,!cap_mknod,!cap_lease,!cap_audit_write,!cap_audit_control,!cap_mac_override,!cap_mac_admin,!cap_syslog,!cap_wake_alarm,!cap_block_suspend,!cap_audit_read,!cap_perfmon,!cap_bpf,!cap_checkpoint_restore
Securebits: 00/0x0/1'b0
 secure-noroot: no (unlocked)
 secure-no-suid-fixup: no (unlocked)
 secure-keep-caps: no (unlocked)
 secure-no-ambient-raise: no (unlocked)
uid=1000(appuser) euid=1000(appuser)
gid=1000(appuser)
groups=1000(appuser)
Guessed mode: UNCERTAIN (0)

cap_net_bind_service is present in Bounding set. Reading this, I would expect the container to be able to nc -l -p 80 without this limitation. But it is prevented. Why ? What am I missing to explain nc -l -p 80 is failling

For additional investigation, the nc -l -p 80 command works if I start the container with podman run --rm -it --cap-add "cap_net_bind_service" tmp

---

Comparing with docker, the same command to build and run the image end with the ability to run nc -l -v 80. Despite having similar capsh --print result. (there is 3 more cap as expected, but nothing related to cap_net_bind_service one)

[sbrivio-rh]

cap_net_bind_service is present in Bounding set

Careful: the bounding set is a set limiting the capabilities that a file can have (bound). Permitted capabilities are something different, and those are what --cap-add "cap_net_bind_service" adds.

See also the "Capability bounding set" section in capabilities(7).

[rhatdan]

A rootless container and rootless user by default can only bind to containers > 1024. This is a hard rule of the OS.

You can lower this boundary via a systemctl.

https://github.com/containers/podman/blob/main/rootless.md

[worming004]

I have to find out why docker doesn't have the same behavior. But all your explainations answered my original question. Thanks

[rhatdan]

You are probably using a docker daemon running as root and talking to it from a rootless user. If you run Docker in the rootless mode, you will have the same issue.