# can't ping as non-root with vanilla-kernel 4.3.3

## flatelin

When I run with vanilla-kernel 4.2.2, ping works fine for my regular user.

When I run with vanilla-kernel 4.3.3, ping only works for root. A regular user gets the error "ping: icmp open socket: Operation not permitted"

Of course, no matter which kernel I run, the permissions of /bin/ping remain the same:

bash(0)$ ls -l `which ping`

-rwx--x--x 1 root root 39736 Dec 2  2014 /bin/ping

I was a little surprised to see that the ping exe doesn't have the suid bit set, but I checked on another machine and the permissions are the same on that machine, too. That machine runs vanilla kernel 4.4.0, btw, and ping works fine for my user. I have not tried 4.4.0 on my problem machine since that kernel isn't supported yet by nvidia-drivers.

But anyway, since ping works under one kernel but not under another, I feel this has to be kernel related. Can anyone tell me what's going on?

----------

## khayyam

flatelin ...

please post the output of the following:

```
# getcap /bin/ping

# emerge -pvq iputils
```

I suspect that extended attributes are used in place of suid.

best ... khay

----------

## flatelin

bash(0)$ getcap /bin/ping

Failed to get capabilities of file `/bin/ping' (Operation not supported)

bash(0)$ emerge -pvq iputils

[ebuild   R   ] net-misc/iputils-20121221-r1  USE="filecaps ipv6 ssl -SECURITY_HAZARD -caps -doc -gnutls -idn -static"

----------

## flatelin

When I run kernel 4.2.2, get caps returns:

/bin/ping = cap_net_raw+ep

----------

## khayyam

 *flatelin wrote:*   

> [ebuild   R   ] net-misc/iputils-20121221-r1  USE="filecaps ipv6 ssl -SECURITY_HAZARD -caps -doc -gnutls -idn -static"

 

flatelin ... I would expect you would have both +USE for caps and filecaps, without the former then 'setcap' (from sys-libs/libcap ... and used in pkg_postinst) isn't available.

```
# equery -NC u iputils | grep caps

 + + caps            : Use Linux capabilities library to control privilege

 + + filecaps        : Use Linux file capabilities to control privilege rather than set*id (this is orthogonal to USE=caps which uses capabilities at runtime e.g. libcap)

# awk -v RS="\n\n" '/pkg_postinst/{print}' ~portdir/net-misc/iputils/iputils-20121221-r1.ebuild

pkg_postinst() {

   fcaps cap_net_raw \

      bin/{ar,}ping \

      $(ipv6 bin/ping6) \

      usr/bin/clockdiff

}
```

EDIT: didn't notice your subsequent post:

 *flatelin wrote:*   

> When I run kernel 4.2.2, get caps returns:
> 
> /bin/ping = cap_net_raw+ep

 

Check FS_POSIX_ACL for whatever filesystem is in use:

```
CONFIG_EXT4_FS_POSIX_ACL=y

CONFIG_FS_POSIX_ACL=y

CONFIG_TMPFS_POSIX_ACL=y

# CONFIG_HFSPLUS_FS_POSIX_ACL is not set
```

best ... khay

----------

## mv

 *khayyam wrote:*   

> Check FS_POSIX_ACL for whatever filesystem is in use

 

You don't need FS_POSIX_ACL for caps. You do need FS_SECURITY

----------

## flatelin

Okay, the mystery deepens.

I have FS_SECURITY set for ext3 and the file system is ext3, but while kernel 4.2.2 correctly identifies the file system as ext3, for some reason kernel 4.3.3 identifies the file system as ext2 and I do not have FS_SECURITY set for ext2 in any of my kernels since I don't have any ext2 file systems.

BTW, adding the "caps" use flag has fixed my initial problem: non-root users can now ping. But now I'm more worried about why the new kernel would misidentify the file system. Any idea why 4.3.3 would incorrectly identify an ext3 file system as ext2?

----------

## flatelin

Should I mark this thread as solved and start a new thread as to why the kernel is misidentifying my file system or is it kosher to keep debugging in this same thread?

----------

## mv

 *flatelin wrote:*   

> Any idea why 4.3.3 would incorrectly identify an ext3 file system as ext2?

 

IIRC, the kernel has removed the ext2 and ext3 driver (internally), that is, everything is done now by the ext4 driver. I don't know how much the user sees from this internal change, but I can imagine that ext3 is now considered as ext4 just without the special ext4 features being set

----------

## s4e8

Another way is add "net.ipv4.ping_group_range = 1000 2000" to sysctl.conf, your user group must be between 1000-2000.

----------

