fix(packet): allow privileged local ports

[Komzpa]

Fixes #421.

Stacked on #647.

Summary

• accept --localport values in the full UDP port range 1..65535 instead of rejecting ports below 1024 in the UI and mtr-packet parser
• keep shared port bounds in packet/ports.h so UI validation, packet parsing, source-port rotation, and permission checks use the same definitions
• require raw UDP probes with an explicit privileged local source port to pass a real UDP bind() preflight after capability dropping
• report a focused error when a low UDP source port is requested but the OS denies the bind
• document that ports below 1024 only work when the operating system allows the packet helper to bind privileged local ports
• cover low UDP local-port handling in the existing UDP probe tests

Security note

This branch no longer keeps or re-enables CAP_NET_BIND_SERVICE after startup. With #647 below it, mtr-packet drops all capabilities permanently after privileged socket setup.

Raw UDP packet construction can otherwise place a privileged source port directly in the UDP header. To avoid bypassing the kernel's local-port policy, this branch performs a real UDP bind() check for explicit low local ports on the raw-socket path. A low local port therefore succeeds only if the OS allows the bind without later capability re-enabling; otherwise it fails cleanly with permission-denied.

Validation

• ./bootstrap.sh && ./configure --without-gtk --without-jansson && make -j$(nproc)
• git diff --check
• make check TESTS='test/capability-drop.py'
• sudo python3 ./test/cmdparse.py
• sudo python3 ./test/probe.py TestProbeUDP
• composite newest-to-oldest stack including fix(packet): drop capabilities permanently #647, fix(packet): allow privileged local ports #611, test(dist): cover tarball version metadata #638, fix(curses): show decimal latency scale #637, test(curses): cover large count formatting #636, feat(curses): add compact startup and scale controls #580, feat(curses): show host and protocol in title #576, and csv: omit trailing empty header field #575: clean merge after rebasing the dependent branch heads
• ./bootstrap.sh && ./configure --without-gtk --without-jansson && make -j$(nproc) on that composite stack
• git diff --check on that composite stack
• make check TESTS='test/capability-drop.py test/dist-version.sh format-count-test' on that composite stack
• sudo python3 ./test/cmdparse.py on that composite stack
• sudo python3 ./test/probe.py TestProbeUDP on that composite stack

[rewolff]

Not entirely sure what you want to do.

My reasoning is that it should not be possible to leverage the elevated privileges that MTR requires to open raw sockets to obtain privileged ports.

So for this to be accepted you need to convince me that this is the case. Just outright refusing to use privileged ports is IMHO safe and reduces functionality only a very little bit. (the "rsh" protocol relies on a privileged source port. And this is no longer used. What are the chances that a port specific routing issue needs to be diagnosed going forward?)

[Komzpa]

Thanks, that concern makes sense.

This PR came from #421 rather than from a strong preference of mine. The intended behavior is only: if an operator explicitly asks for --localport 80 (or another low UDP source port), mtr should pass that request through instead of rejecting it before the kernel sees it. It is not meant to make mtr-packet's raw-socket privilege sufficient to bind a privileged source port.

The safety boundary I was relying on is the OS bind permission itself: with only the usual raw-socket capability, binding low UDP source ports still fails; it only succeeds when mtr-packet also runs as root or has CAP_NET_BIND_SERVICE. I updated the branch to document that explicitly and added a UDP probe test for local-port 80 under the root-run probe tests.

That said, I do not have a strong stake in changing this policy. If you prefer the existing conservative behavior, rejecting this PR is fine. If #421's use case is worth supporting, this PR is also ready to merge. It is independent of the other packet/port changes; either direction can be accepted or rejected separately.

[rewolff]

If we were to allow this, mtr would have to be audited that people don't use mtr to elevate privileges or "mess up the network" (denial of service) by sending "bad" packets onto the network. People will have to find their own solution if they find it necessary to use a privileged port.

[Komzpa]

@rewolff I have no preference here but if you do then please also deal with #421 which lead to this PR