16

I am running a vserver environment with several virtual machines. A single VM has the following problem:

$ ping 8.8.8.8
ping: icmp open socket: Operation not permitted

$ ls -l $(which ping)
-rwsr-xr-x 1 root root 30736 2007-01-31 00:10 /bin/ping

$ whoami
root

$ mount
/dev/hdv1 on / type ufs (defaults)
none on /proc type proc (0)
none on /tmp type tmpfs (size=16m,mode=1777)
none on /dev/pts type devpts (gid=5,mode=620)

$ uname -a
Linux v-web1 2.6.27.55-vs2.3.0.36.9 #1 SMP Tue Apr 28 11:35:00 CEST 2015 i686 GNU/Linux

Note that on the host machine as well as on all other VM hostet there, Ping works fine.

Does anyone have any idea to help me, please?

Improve this question
3
  • Is /bin/ping set-uid on the other machines? Is TCP/IP correctly set up on this VM? Do other things work like DNS, traceroute, HTTP?
    – David Schwartz
    Commented Jun 3, 2015 at 10:38
  • 3
    Did you try to reinstall iputils-ping ?
    – Nabil Bourenane
    Commented Jun 3, 2015 at 10:42
  • Another information may be useful: This is a highly productive machine running Apache with about 5 to 7 accesses per second - so no idea about modifying the network configuration. It has moved to a new hardware last night, and since then, Munin shows that Ping ain't working.
    – rexkogitans
    Commented Jun 3, 2015 at 11:30

3 Answers 3

Reset to default
19

TL;DR version: reinstall iputils-ping

I have seen online where it has been suggested to use 

chmod u+s $( which ping );

However this will permit the user to change the preload and flood. Which could result in a USER being able to Denial Of Service either your local machine or another machine or your network.

I tried what @nabil-bourenane suggested, reinstalling iputils-ping which resolved the issue for me and doesn't have the SUID bit set. 

username@server:~$ ls -l $( which ping );
-rwxr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping

If the SUID bit is set it will look like

username@server:~$ ls -l $( which ping );
-rwsr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping
Improve this answer
5
  • 1
    If you're already root, SUID root binaries won't change much.
    – Falcon Momot
    Commented Aug 31, 2015 at 8:36
  • @FalconMomot, I appended the solution.
    – rexkogitans
    Commented Nov 9, 2015 at 8:06
  • Reinstalling iputils (same version before/after) worked for me on centos7. Before, getcap /bin/ping showed no capabilities set. After reinstall, getcap /bin/ping returned: /bin/ping = cap_net_admin,cap_net_raw+p. Now the question is: why it lost the capabilities. rpm --verify iputils did show that ping, arping and clockdiff all showed that the cap settings had changed (before the reinstall).
    – Juan
    Commented Jan 31, 2020 at 1:34
  • In my case, it may have lost file capabilities after a restore from a dump image. See also unix.com/unix-for-advanced-and-expert-users/…. In that case, they used tar. In my case, I was hoping dump/restore preserved all those file attributes (attrs, capabilities, acls, etc.). I'm surprised it didn't, so I'll have to see if I can reproduce it (and then maybe log a bug).
    – Juan
    Commented Jan 31, 2020 at 1:53
  • reinstalling did the trick for me! You have to explicitly remove it, 'apt remove iputils-ping' and install it again with 'apt install iputils-ping'
    – Eelco van Vliet
    Commented Jul 28, 2022 at 1:54
3

The solution is to set Linux System Capabilites to allow raw socket on the host machine.

Since this is a very v-server specific problem, the solution is to create a single-lined file named /etc/vservers/VMNAME/bcapabilities:

NET_RAW

and reboot VM.

Improve this answer
2
  • 1
    "And how do you accomplish this?" would be useful as a complete answer.
    – ILMostro_7
    Commented Nov 7, 2015 at 1:21
  • After 4 years, I changed the accepted answer to mine, because it REALLY ANSWERS THE QUESTION. This is v-server problem and has nothing to do with the file mode of the ping executable.
    – rexkogitans
    Commented May 17, 2019 at 7:32
3

Sorry I can't comment. This problem hit me after I extracting an archive of a working system over a minimal installation.

All above answers work. But the one proposed by @Nabil Bourenane and @Linx is prefered for security. To answer @rexkogitans's comment, here I quote from iputils-ping.postinst (/var/lib/dpkg/info/...)

if command -v setcap > /dev/null; then
    if setcap cap_net_raw+ep /bin/ping; then
        chmod u-s /bin/ping
    else
        echo "Setcap failed on /bin/ping, falling back to setuid" >&2
        chmod u+s /bin/ping
    fi
else
    echo "Setcap is not installed, falling back to setuid" >&2
    chmod u+s /bin/ping
fi

which basically says when configuring iputils-ping, first try setcap then if that fails use chmod u+s. That's why reinstalling iputils-ping works.

Improve this answer
3
  • 1
    So this will work: setcap cap_net_raw+ep /bin/ping
    – rlf
    Commented Jun 5, 2018 at 21:39
  • It was not my comment, but my answer to my own question. The problem cannot be solved from within the container, so whatever the post install hook does is pointless.
    – rexkogitans
    Commented Jun 6, 2018 at 10:03
  • 1
    Indeed, setcap cap_net_raw+p $(which ping) as root fixes it. There is a thorough explanation on this blog post: Linux Capabilities and Ping
    – mivk
    Commented Oct 6, 2018 at 15:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .