# [SOLVED] ping: icmp open socket: Operation not permitted

## AaylaSecura

Greetings! I just noticed I can no longer run ping as a regular user. Can't tell when exactly that happened though. Any host I would try to ping gives::

```
ping: icmp open socket: Operation not permitted
```

ping as root works fine. Searching online suggested that ping should either be set with capabilities cap_net_raw=ep or setuid. Triing the former one resulted in:

```
setcap cap_net_raw=ep $(which ping)
```

Setting the suid bit of course "fixes" that but I don't think I should have to resort to this - it never had this bit set. I thought it may be related to the recent updates (kernel 3.19.3 -> 4.0.0), but booting with the old kernel made no difference. The only network related package that was updated in the last month was iproute2, but reverting to the previous version (4.0.0 -> 3.19.0) made no differece either. Here's the output of strace -e open ping -c1 localhost as root:

```
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3

open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3

open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4

open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 4

open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 4

open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4

open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 4

open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 4

open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4

open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4

PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.

64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.072 ms

--- localhost.localdomain ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms

+++ exited with 0 +++

```

and as a regular user:

```
open(0x7fd9ac82cb96, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9aca2cf92, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9ac5d9490, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9ac5d9490, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9ac5d95cc, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9ac82cb96, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9aca26903, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9ac5d94d7, O_RDONLY|O_CLOEXEC) = 3

open(0x7fd9ac270bf1, O_RDONLY|O_CLOEXEC) = 3

ping: icmp open socket: Operation not permitted

+++ exited with 2 +++

```

I don't see anything wrong (apart from the error, that is). The fact that baselayout (providing ping) hasn't been updated for a long time makes me think the problem lies somewhere else. Shooting in the dark: ip table looks normal:

```
Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

0.0.0.0         192.168.0.1     0.0.0.0         UG    2003   0        0 wlan0

127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo

127.0.0.0       127.0.0.1       255.0.0.0       UG    0      0        0 lo

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
```

No rules are defined in iptables, all chains default to ACCEPT. I'm out of ideas...

P.S. The whole system is ~amd64Last edited by AaylaSecura on Mon Apr 20, 2015 10:54 pm; edited 1 time in total

----------

## Apheus

/bin/ping is provided by net-misc/iputils, and a remerge of that package solves the problem. At least here with a stable 64 Bit virtualbox guest with hardened-sources kernel. Don't know why, only idea would be extended file attributes having been damaged somehow.

----------

## AaylaSecura

 *Apheus wrote:*   

> /bin/ping is provided by net-misc/iputils, and a remerge of that package solves the problem. At least here with a stable 64 Bit virtualbox guest with hardened-sources kernel. Don't know why, only idea would be extended file attributes having been damaged somehow.

 

Thank for replying! My bad, indeed it was iputils (I checked, but then I checked another file that was provided by baselayout and it was late at night...)

I thought it may have to do with the extended attributes and the following confirms it:

* Could not set caps on '/bin/ping' due to missing filesystem support:

 * * enable XATTR support for 'ext2/ext3' in your kernel (if configurable)

 * * mount the fs with the user_xattr option (if not the default)

 I use ext4 and I DID enable xattr a long time ago using:

```
tune2fs -o user_xattr /dev/sda1
```

but I just saw that CONFIG_EXT4_FS_SECURITY was missing from my kernel, so there was no support for it. Don't know how I missed it but adding this to the kernel and reemerging iputils fixes the problem indeed. Thanks!

----------

