Ping operation not permitted linux

ping: socket: Operation not permitted

This document (000020581) is provided subject to the disclaimer at the end of this document.

Environment

Situation

The ping command returns ‘Error: ping: socket: Operation not permitted’ when executed by a non-root user.

node1: # su test test@node1:/> ping -c1 8.8.8.8 ping: socket: Operation not permitted test@node1:/>

In some cases, it might not return an error message, but it might not actually perform the ping, either:

node1: # su test test@node1:/> ping -c1 8.8.8.8 node1: #

Resolution

There are various methods to allow non-root users to execute ping. On most SLES systems, one or more of these are already present after a standard install, so most systems do not run into this issue. The following methods are all independent. Choosing one of them should be enough.

1. The parameter: net.ipv4.ping_group_range

This parameter will allow non-root users to execute ping on SLES 15. However, due to potential problems in the usage of this parameter, SUSE is recommending this ONLY for 15 SP3 and above. Additionally, this will not solve the issue on SLES 12, even though the parameter exists there also. On those previous distributions, leave this setting at the default of «1 0» and see option #2 or #3 instead, below.

The ping_group_range can be set within /etc/sysctl.conf:

net.ipv4.ping_group_range="0 2147483647"

sysctl net.ipv4.ping_group_range="0 2147483647"

node1:~ # sysctl net.ipv4.ping_group_range net.ipv4.ping_group_range = 0 2147483647 node1:~ # node1:~ # su test test@node1:/> ping -c1 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.62 ms --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.620/3.620/3.620/0.000 ms test@node1:/>

2. Alternatively, non-root users can use the ping command if certain capabilities are present on the /usr/bin/ping binary:

node1:~ # setcap cap_net_raw+p /usr/bin/ping node1:~ # getcap /usr/bin/ping /usr/bin/ping = cap_net_raw+p node1:~ # node1:~ # su test test@node1:/> ping -c1 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=3.62 ms --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 3.620/3.620/3.620/0.000 ms test@node1:/>

The above capability method allows more fine grained privileges to be given to non-root users rather than the full power of root. Testing and research confirm that «cap_net_raw+p» on /usr/bin/ping should be enough to allow non-root users to ping. However, most SLES 12 and 15 installations have defaulted to «cap_net_raw+ep» so if any problems are seen with +p, it may be worth testing +ep as well.

* In order to use getcap and setcap commands, the libcap-progs package must be installed, which can be done with the command:

zypper install libcap-progs

3. In some unique circumstances, the permissions mode of /usr/bin/ping may need to be increased to allow execution by non-root users. This method is no longer preferred, as it carries more security risk. In older distributions of Linux, such as SLES 11, ping was typically made accessible to non-root users by setting the «setuid» bit on /usr/bin/ping:

# chmod 4755 /usr/bin/ping # ls -l /usr/bin/ping -rwsr-xr-x 1 root root 72664 May 7 15:39 /usr/bin/ping

Note the «s» in the permissions displayed above. This represents the «setuid» bit and allows non-root users to execute as the owner (root).

However, for security reasons, using the setuid bit is no longer a preferred method. It is safer to use options #1 or #2 above.

Despite that warning, if SLES 12 is in use and /usr/bin/ping resides on an NFS mount (typically when the root file systems is an NFS mount) then neither method #1 nor #2 will allow non-root users to execute ping. In that case, it is necessary to add the setuid bit as shown above. Note that for SLES 15 SP3 (and above) with an NFS mount, method #1 above is sufficient and preferred.

Some administrative commands might remove the setuid bit from certain executables which are not intended to have it. To make the setuid bit more permanent, edit /etc/permissions.local and add these 2 lines:

/usr/bin/ping root:root 4755 /usr/bin/ping6 root:root 4755

Cause

Because of security concerns, traditional methods of allowing non-root users to execute ping (and to obtain sockets) have evolved over time. Because of these changes, configuration may occasionally need to be verified.

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented «AS IS» WITHOUT WARRANTY OF ANY KIND.

• Document ID:000020581
• Creation Date: 24-Oct-2022
• Modified Date:24-Oct-2022
• • SUSE Linux Enterprise Server

  For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

  Источник

  ping: operation not permitted

  Есть шлюз в инет (инет спутниковый). До некоторого времени все работало отлично (гдето с пол года назад его поставил). Но сейчас такая проблема с сетью:

  Перегружаешься. Гдето около дня работает нормально. Потом при пинге чего либо (не обязательно в инете, пробывал и adsl-router пинговать) ping возврашяет сообщение:

  ping: operation not permitted

  На сколько мне известно, это значит что отказано ещё до посылки пакета. Т.е. проблема непосредственно с этой машиной.

  Фаервол пробывал отрубать (все чепочки в ACCEPT).

  Соседнюю машину 50 дней не ребутал и все отлично (система одинаковая).

  что это может быть? с чем это связано? железо? система?

  Железо: корпус с источником питания, материнка, CPU pI-150 Mhz, MEM 32 Mb, hdd 544 Mb, Ethernet RTL-8139, DVB карта SkyStar2 (rev 2.6 d). Больше ничего нет.

  

  Re: ping: operation not permitted

  Фаервол пробывал отрубать (все чепочки в ACCEPT).

  Энто ещё ни о чём не говорит. Скорее всего что-то типа —icmp-type 8 -j DROP.

  Re: ping: operation not permitted

  На сколько я знаю, это может быть связано не только с firewall-ом, но и например с кол-вом одновременных соединений, т.е. с переполнением conntrack таблицы. Обычно об этом система сообщает в логах. Помогает увеличение размера таблицы.

  

  Re: ping: operation not permitted

  >Обычно об этом система сообщает в логах

  Она орёт об этом в консоль 🙂

  Re: ping: operation not permitted

  > Энто ещё ни о чём не говорит. Скорее всего что-то типа --icmp-type 8 -j DROP. я его так отрубал: $IPTABLES -F $IPTABLES -X $IPTABLES -t nat -F $IPTABLES -t nat -X $IPTABLES -P INPUT ACCEPT $IPTABLES -P FORWARD ACCEPT $IPTABLES -P OUTPUT ACCEPT $IPTABLES -t nat -P POSTROUTING ACCEPT $IPTABLES -t nat -P PREROUTING ACCEPT в данном случае ICMP он не должен зарезать.

  Re: ping: operation not permitted

  q> Обычно об этом система сообщает в логах. Помогает увеличение размера таблицы.

  > Она орёт об этом в консоль 🙂

  у меня на этой машине не видюхи не моника нет. только по ssh. В такую консоль тоже орать будет?

  но во всяком случае ничего не нашел ни в логах ни в конслое (когда удаленно на него захожу).

  Re: ping: operation not permitted

  Feb 24 10:25:56 sam-gw kernel: printk: 2 messages suppressed.

  Feb 24 10:25:56 sam-gw kernel: ip_conntrack: table full, dropping packet.

  Feb 24 10:26:01 sam-gw kernel: printk: 3 messages suppressed.

  Feb 24 10:26:01 sam-gw kernel: ip_conntrack: table full, dropping packet.

  Ич что дальше делать? Как с этой чертовой conntrack таблицей работать?

  Re: ping: operation not permitted

  и сколько туда записать? у меня там щас 2048.

  нет никакого howto никакой доки про все это? про то где как в линухе лучше че настраивать с сетью (я имею такие вещи, которые в /proc/sys/net/ipv4 лежат)

  Re: ping: operation not permitted

  На самом деле увеличение таблицы имхо не решение проблемы, т.к. это значит о том, что система не может отправить пакет дальше. Увеличенеи таблицы целесообразна при больших нагрузках на сервер, а если у тебя просто пинг не идет — то тут что-то странное (не сталкивался)

  Re: ping: operation not permitted

  Feb 24 10:25:56 sam-gw kernel: ip_conntrack: table full, dropping packet.

  значит таблици не хватает

  хотя согласен с тем что просто так увеличивать не стоит. ну будет она больше ну все рвано переполниться.

  я увеличил с 2048 до 8192

  может есть какие подводные камни, связанные с тем что на этом шлюзе настроен инет спутниковый? Земной GW у меня мой adsl-modem на одном свиче висят. На провайдера (спут.) поднимаю gre-туннел. Дрова для SkyStar2 из ядра (2.6.10).

  Может быть машинка слабая, хотя работает вроде как нормально, ниче не тормозит, пока с таблица переполниться. Хотя и когда переполниться то проц не жрет.

  Прям щас нашел еще один баг:

  своп был отрублен. раньше работал, а щас:

  root@sam-gw:/etc/sky# cat /proc/swaps

  swapon: /dev/hda2: Invalid argument

  пока не сделал mkswap /dev/hda2 так и не подрубался. Может чето было с хародом (с /dev/hda2). Щас подрубился.

  Источник

  ping socket: Permission denied

  For this problem, we should add the following lines to /etc/group :

  inet:x:3003:root net_raw:x:3004:root 

  Thank you, but can you explain why this should work, and what it does? It didn’t solve the issue for me..

  The underlying ping is using sock_raw. To create such a socket, you must have root privileges.

  int main(void) < rawsock = socket(AF_INET, SOCK_RAW, protocol->p_proto); if(rawsock < 0)< perror("socket"); return -1; >> 

  If the owner of the ping is not root, the error will not be fixed. Using the linux capability mechanism can’t solve the problem.

  I was skeptical but, even when run as root, I see ping’s initial SOCK_DGRAM socket creation failing, so indeed SOCK_RAW ends up being used: socket(AF_INET, SOCK_DGRAM, IPPROTO_ICMP) = -1 EACCES (Permission denied) socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) = 3

  The OP is executing ping as root, so this isn’t an answer to them, more an extended comment on the answer from @leesagacious. In my situation, on CentOS Stream 8, so doubly inappropriate for askubuntu. unless it happens there too, the Linux capability mechanism does appear to the the answer, kudos https://superuser.com/a/1616749/17633:

  [manager@smu-centos8-daily-test ~]$ ping -c 1 8.8.8.8 ping: socket: Operation not permitted [manager@smu-centos8-daily-test ~]$ getcap /usr/bin/ping [manager@smu-centos8-daily-test ~]$ sudo setcap cap_net_raw+p /usr/bin/ping [manager@smu-centos8-daily-test ~]$ ping -c 1 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=4.57 ms --- 8.8.8.8 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.567/4.567/4.567/0.000 ms [manager@smu-centos8-daily-test ~]$ getcap /usr/bin/ping /usr/bin/ping = cap_net_raw+p [manager@smu-centos8-daily-test ~]$ sudo setcap -r /usr/bin/ping [manager@smu-centos8-daily-test ~]$ getcap /usr/bin/ping [manager@smu-centos8-daily-test ~]$ ping -c 1 8.8.8.8 ping: socket: Operation not permitted [manager@smu-centos8-daily-test ~]$ 

  I don’t think that the owner of ping, as opposed to the uid of the process executing ping, would be relevant, except back in the days when ping was setuid.

  Источник

  Ubuntu 14.04 getting ping: sendmsg: Operation not permitted

  The problem is out of my league apparently, Ubuntu cannot access any network but somehow my VMs using virtual box are all able to access the internet. I have attempted to do the following changes but as you can this was not successful. I am very confused as to what is wrong on my box. Any help appreciated.

  carl@carl-Latitude-E6410:~$ sudo ip6tables -P INPUT ACCEPT carl@carl-Latitude-E6410:~$ sudo ip6tables -P OUTPUT ACCEPT carl@carl-Latitude-E6410:~$ sudo ip6tables -P FORWARD ACCEPT carl@carl-Latitude-E6410:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1008ms carl@carl-Latitude-E6410:~$ sudo iptables -P INPUT ACCEPT carl@carl-Latitude-E6410:~$ sudo iptables -P OUTPUT ACCEPT carl@carl-Latitude-E6410:~$ sudo iptables -P FORWARD ACCEPT carl@carl-Latitude-E6410:~$ sudo service iptables restart iptables: unrecognized service carl@carl-Latitude-E6410:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted ^C --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1008ms 

  Flushing the iptables did work. I have conflicting ip rules that came with the cisco VPN client. anyways after flushing and reinstalling the client all is good and back to normal.

  Источник