Support kernel parameter ping_group_range allowing unprivileged users to use ICMP (ping)

[browniebraun]

Today SPINE is only supporting ICMP if running as root -
to verify that it has root permissions capabilities for RAW_NET (hasCaps()) as well as setuid will be taken into account.

Since kernel release 2.6.x parameter ping_group_range will be supported that allows a range of user groups to use RAW sockets for PING as unprivileged users.

Many distributions are supporting that today per default, OpenNMS is also mentioning that option.
( see [https://opennms.discourse.group/t/how-to-allow-unprivileged-users-to-use-icmp-ping/1573] )

The parameter vvalue can be reviewed at CLI level for example with:

browniebraun@browniebraun-Lenovo-ideapad-530S-14IKB:~$ /sbin/sysctl net.ipv4.ping_group_range net.ipv4.ping_group_range = 0 2147483647
If disabled net.ipv4.ping_group_range will return "1 0".

ping.c offers a function called inet_get_ping_group_range_net(), probably this could be used as an entry point for a modification of Spine.

[TheWitness]

@browniebraun, were you going to attempt a pull request?

[somethingwithproof]

Confirming this is still unimplemented, with the specific line.

ping.c:301 opens the ICMP socket as socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) with no SOCK_DGRAM attempt, so net.ipv4.ping_group_range has no effect on Spine regardless of how the sysctl is set. hasCaps()/seteuid(0) remain the only paths.

The change is well scoped: try socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) first and fall back to SOCK_RAW on EACCES/EPERM. The one wrinkle is that on a SOCK_DGRAM ICMP socket the kernel rewrites the echo id, so the reply-matching logic has to tolerate that rather than compare against getpid() & 0xFFFF.

[somethingwithproof]

Fixed in #555.

Two places needed changing, not just the socket call. set.icmp_avail in util.c decides ICMP is unavailable whenever spine is neither root nor capability-endowed, and ping_host() diverts to UDP on that flag before ping_icmp() is ever reached, so patching ping.c alone changed nothing observable. Both the availability probe and the two ping paths now try SOCK_DGRAM before SOCK_RAW.

Two details the datagram socket forces: the kernel strips the IPv4 header from the reply, so the v4 receive path branches on socket type, and it reassigns the echo id, so the v6 reply match drops the id check and relies on sequence, source address and payload.

Verified as uid 65534 with --cap-drop=ALL across three sysctl and privilege combinations.