Dietpi: ping: socket: Operation not permitted

[tetherit]

ADMIN EDIT

Solution

echo 'net.ipv4.ping_group_range = 0 2147483647' > /etc/sysctl.d/99-ping.conf
sysctl -p /etc/sysctl.d/99-ping.conf

Read more

• https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
• https://github.com/systemd/systemd/pull/13141
• https://github.com/systemd/systemd/blob/master/sysctl.d/50-default.conf
• https://github.com/MichaIng/DietPi/commit/caec92e92e136a2f731f6d4c45db8463896fc80a

---

Hi there,

It seems for some reason DietPi is set up in a way where a normal user cannot perform a ping operation?

dietpi@DietPi:~$ ping 192.168.88.14
ping: socket: Operation not permitted
dietpi@DietPi:~$ sudo ping 192.168.88.14
PING 192.168.88.14 (192.168.88.14) 56(84) bytes of data.
64 bytes from 192.168.88.14: icmp_seq=1 ttl=64 time=1.05 ms

Is there a special reason for this or is this a bug?

[Fourdee]

@xanview

normal user cannot perform a ping operation

Seems permissions need to be set on the ping binary for underpriv users to run this:
https://www.raspberrypi.org/forums/viewtopic.php?p=874479&sid=679670d4747d3e00e7885a18ac71e7f4#p874479

[Fourdee]

Marking as resolved, please reopen if required.

[gade-raghav]

use the following command.
sudo ping "your ip addr or host name"

[Jewsh-S]

Find the location of the ping binary in case it's not normal using "type ping". Then give it privileges to use as non root user "chmod +s /bin/ping" or "chmod +s /location/of/ping"

[MichaIng]

Or use this one-liner:

sudo chmod 755 $(which ping)

This should be actually the default permissions, however we observed much stranger setups in cases 😄.
EDIT: The binary is world-executable, hence this is not the issue. The missing capabilities for the binary itself when being executes with unprivileged user is, see possible solution below 👍.

[jerinisready]

This seems to be working here

sudo setcap 'cap_net_admin,cap_net_raw+ep' $(which ping)

[MikeHigginbottom]

sudo setcap 'cap_net_admin,cap_net_raw+ep' $(which ping)

This is probably the correct answer.

Doing a sudo ping <host> is probably what the kernel developers intended you to do since it's not really supposed to be run by normal users but it's pretty much considered an everyday tool these days and sudoing every time is a bit of a pain.

Adding the 'setuid' bit with chmod +s /bin/ping is what most Linux distros seem to do but it's a bit of a security concern because it grants ALL the rights of a super user.

The setcap approach grants much more restricted rights by only allowing it the specific capabilities it needs.

[MichaIng]

@MikeHigginbottom
Thanks for explaining this a bid. Yes granting only the specifically required capabilities.

I just checked what is default on Debian:

root@VM-Building:~# getcap /bin/ping
/bin/ping = cap_net_raw+ep

This seems to be sufficient, since I can ping which any unprivileged user. Of course the iputils-ping ships several more feature than performing simple ping, probably for one of those cap_net_admin is required.

[MikeHigginbottom]

Mmm. Suspect you're right about cap_net_admin. I can ping localhost from my sandbox iputils build on Ubuntu without it.

OT but... Interestingly Ubuntu does the setuid thing rather than using capabilities which is weird considering what you're seeing on Debian. Maybe the Ubuntu devs made a conscious decision to override the Debian choice and use setuid for some reason?

[MichaIng]

@MikeHigginbottom
No idea why Ubuntu handles it differently. Perhaps it is simply a failsafe step to assure that it can do all it needs for all features/options it has. In the end, if you trust the ping binary, and everyone can check the source code, then you can grant it super user permissions. I am just conservative here, also to prevent from bugs, human errors, very unlucky file corruptions or whichever thinkable thing 😉.

[datdinhquoc]

use the following command.
sudo ping "your ip addr or host name"

using sudo works, but my user is already in 'wheel' group ('sudo' group); i just can't guess out why i need sudo, any ideas?

[MichaIng]

The sudo/wheel group only allows you to call sudo, but it does not replace the sudo call. Either you need to use sudo or you need to grant the binary itself the capabilities as mentioned here: https://github.com/MichaIng/DietPi/issues/1012#issuecomment-569012816

[datdinhquoc]

The sudo/wheel group only allows you to call sudo, but it does not replace the sudo call. Either you need to use sudo or you need to grant the binary itself the capabilities as mentioned here: #1012 (comment)

i can ping without sudo now (suggested by Jewsh-S above):
sudo chmod +s /usr/bin/ping
ping google.com

[MichaIng]

@datdinhquoc
While this works, from security perspective it is not optimal. With this, every user that executes the binary has full root privileges through it. This solution only grants additionally cap_net_admin capabilities, which is sufficient.

---

Related to IPv6 connection issue investigation I found another solution:

sysctl -w net.ipv4.ping_group_range="0 $(getent group sudo | cut -d: -f3)"
# To make the change boot-persistent, add the setting to /etc/sysctl.conf or /etc/sysctl.d/yourFile.conf

This enables/permits "ping sockets" for all members of groups from ID 0 (root) until the ID of the sudo group. Could be done more specific or elegant of course. This is disabled by default (Debian Stretch at least) which makes ping fail to bind to a ping socket, falling back to a raw socket, which is probably what requires cap_net_admin:

# ping -v4 github.com
ping: socket: Permission denied, attempting raw socket...
...

[MichaIng]

Found further info about this, some distros enable it by default for all users, so no sudo, setuid, CAP_NET_ADMIN or CAP_NET_RAW is required:

• https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
• Back and forth on systemd, finally it's their upstream default: https://github.com/systemd/systemd/pull/13141