Listening port check is rather naive

[the-maldridge]

Some part of the code base is naively checking the effective UID and is dissallowing bind of system ports when not running as root. This ignores the case where CAP_NET_BIND is available in the current context.

I can't find in a cursory search where the check happens in the code, otherwise I would have sent a patch.

[brzd]

Is this the reason that I am not able to change webUI port to other than 8000?

[qdm12]

@the-maldridge sure but what's your use case really? Why would you want to listen on privileged ports?

@brzd no, you can set the listening port between 1024 and 65535

[drewstopherlee]

Not sure if it's directly related, but I'm running into a similar issue when starting the container since updating to latest: (EDIT: my bug is only present in the 'latest' image, but when I manually set version 2.5.0, this bug goes away.)

ERROR settings validation: resolver settings: splitting host and port from address: cannot use privileged ports (1 to 1023) when running without root: 53

Due to split DNS, I have to use the RESOLVER_ADDRESS environment variable and it kicks this error every time I restart the container. It's currently running on a Ubuntu Server 22.04 on a Raspberry Pi, so when I try to add user: root to the docker-compose, it fails to deploy. If this needs to be a separate issue, please let me know and I'll open one.

[qdm12]

@drewstopherlee unrelated-ish, but that's a bug that got introduced after v2.5.0 (on the latest image, you can check your logs for the version you're running). I just fixed it in 4922b1db0bf21cd9e78eb58a78d2ee6232f0e071 since the resolver address should NOT be validated as a listening address anyway.

[drewstopherlee]

@drewstopherlee unrelated-ish, but that's a bug that got introduced after v2.5.0 (on the latest image, you can check your logs for the version you're running).

Yep, I noticed it and edited my comment right before you replied. Thanks so much!

[the-maldridge]

Been a while since I looked back into this since I worked around the bug via other means, but I'm refactoring some things and ran back into this. At its core that this is a bug due to incorrect assumptions around bind permissions. A service need not be root nor even have any capabilities to bind "privileged" ports, and given that its entirely feasible to adjust the port boundary or remove it entirely, the check is flawed at best.

Since you wanted a use case though I can explain what I'm currently refactoring to, which is that I have containers using a dynamic macvlan architecture for networking where BGP is announcing a service VIP per-host per-container based on wherever the container happens to be at the moment. This is the one container in my entire fleet which does not put a webserver on port 80, and it is the last one I have notes for that I have to access it on a non-standard port. I guess I can kludge around it by running an nginx sidecar and having that map the traffic, but that's pretty clunky.

Edit: For those curious how to adjust the start of privileged ports on your system, the tunable you're looking for is net.ipv4.ip_unprivileged_port_start, which takes a port number inclusive of the lower bound you desire.

[qdm12]

This makes sense, thanks for sharing! I'll get to it right now, sorry for the delay.

[qdm12]

Hi @the-maldridge c51a41e1a4be9e364ef0f2ab3186fed501e24b2f has fixes for the settings validation library (juicy details at https://github.com/qdm12/gosettings/commit/75485e040faabcbfa542a1381d6074fe99cc0ce4) such that:

• it reads the start of unprivileged ports from /proc/sys/net/ipv4/ip_unprivileged_port_start on Linux platforms
• it checks for the running program having effective and permitted net_bind_service capability

Let me know how it goes 😉 !