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?

rexkogitans
  • 324
  • 1
  • 2
  • 20
  • 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 Jun 03 '15 at 10:38
  • 2
    Did you try to reinstall iputils-ping ? – Nabil Bourenane Jun 03 '15 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 Jun 03 '15 at 11:30

3 Answers3

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
Community
  • 1
Linx
  • 398
  • 4
  • 10
  • 1
    If you're already root, SUID root binaries won't change much. – Falcon Momot Aug 31 '15 at 08:36
  • @FalconMomot, I appended the solution. – rexkogitans Nov 09 '15 at 08: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 Jan 31 '20 at 01:34
  • In my case, it may have lost file capabilities after a restore from a dump image. See also https://www.unix.com/unix-for-advanced-and-expert-users/280278-centos7-restoring-file-capabilities.html. 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 Jan 31 '20 at 01: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 Jul 28 '22 at 01: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.

rexkogitans
  • 324
  • 1
  • 2
  • 20
  • 1
    "And how do you accomplish this?" would be useful as a complete answer. – ILMostro_7 Nov 07 '15 at 01: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 May 17 '19 at 07: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.

rlf
  • 41
  • 1
  • 1
    So this will work: setcap cap_net_raw+ep /bin/ping – rlf Jun 05 '18 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 Jun 06 '18 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](http://unixetc.co.uk/2016/05/30/linux-capabilities-and-ping/) – mivk Oct 06 '18 at 15:08