Linux ping операция не позволена

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ping: socket: Operation not permitted #1012

ping: socket: Operation not permitted #1012

Comments

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

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?

The text was updated successfully, but these errors were encountered:

Marking as resolved, please reopen if required.

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

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»

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 👍 .

This seems to be working here

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

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

This is probably the correct answer.

Doing a sudo ping 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.

@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.

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?

@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 😉 .

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?

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)

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

@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. . 

Источник

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.

Источник

ping: socket: Operation not permitted Ubuntu docker image

Hi i am new to docker and linux. I am trying to ping a particular ip address from a python file in a container built on ubuntu 18.04 base. I get the following error when the kubernetes pod container is ran on CentOS OS but it runs fine on Ubuntu OS

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the ‘nosuid’ option set or an NFS file system without root privileges?

I am trying to run the container as a normal user. I have a security context in the container deployment yaml as below:

fsGroup: 2000 runAsNonRoot: true runAsUser: 1000 

RUN adduser --disabled-password --gecos '' RUN adduser sudo RUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers USER

subprocess.check_call(f"sudo ping -c 3 ") 

1 Answer 1

Rationale

The error message you face with Kubernetes on CentOS already gives a hint about how sudo is working: It makes use of the setuid bit to have it effectively executed as owner of the executable, intended to be root , regardless which user executes it. Two conditions need to be met for this to work:

The underlying filesystem needs to be mounted without the nosuid option, which prevents setuid functionality. You can list all mounts with with this flag e.g. via:

Needless to say that both conditions need to be met on host system level when using a host system kernel feature. I’m no expert with the different container platforms, whether and how they mount the container images and do UNIX user namespace sandboxing, so that sudo within the container may naturally be ineffective for granting host system capabilities.

Solutions

Granting a user full passwordless sudo permissions only to run ping in my personal opinion is no good idea anyway for security reasons, in case it is even possible within Docker. There are safer options to achieve this, I’ll start with the one which should definitely work for your use case and is IMHO the safest from security point of view and continue with two other general solutions, while not recommending them.

It is possible to define UNIX groups which shall have ICMP listen permissions without requiring root privileges. Some Linux distributions even do this by default, the common init system systemd as well does this via their upstream default configuration:

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

setcap 'cap_net_raw+ep' "$(which ping)" 

In your case, solutions 2 and 3 would need to be applied within the container to the container’s ping executable and do only work when there is no sandboxing for executable capabilities respectively UNIX users, i.e. the root user within the container is the same root user on the host for solution 3. That sudo does not work indicates that the the last condition may not be met. Already these limitations in combination with containers and the security benefits IMHO clearly underlines the benefit of solution 1.

Источник