Bug 1501110 - ping -v shows spurious error message of: ping: socket: Permission denied, attempting raw socket...
Summary: ping -v shows spurious error message of: ping: socket: Permission denied, att...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: iputils
Version: 28
Hardware: Unspecified
OS: Linux
low
low
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-12 06:37 UTC by Wayne Pollock
Modified: 2019-05-28 20:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 20:27:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Wayne Pollock 2017-10-12 06:37:48 UTC
Description of problem:

Using ping with -v produces this message.  (It didn't in the past but I don't
know when the bug was introduced, except it was after Fedora 21.)

Version-Release number of selected component (if applicable):

iputils-20161105-5.fc26.x86_64

How reproducible:

Always

Steps to Reproduce:
1.  ping -v anyplace
2.
3.

Actual results:
ping: socket: Permission denied, attempting raw socket...

Expected results:
No such message

Additional info:

This seems more of a debugging message than an informational one, and I'd like to see it removed from the "ping -v" output.

The issue seems to be that the system does support ICMP sockets ("ping" sockets), but by default their use is prohibited in the kernel.

Work-Around:

To allow the use of ICMP sockets by ping, you need to enable them for root:

1.   # sysctl -w net.ipv4.ping_group_range="0 0"

(Aside: this is the silliest security mechanism I've come across in Linux.)
Next, make ping SGID to root:

2.  # chmod g+s /usr/bin/ping

Now ping can use ICMP sockets.

What I don't know is, is this usage safe?  Since "raw" packets seem to work just fine, my first suggestion, eliminating the scary message from "ping -v" output, might be a better solution; I will leave the resolution of this bug to wiser heads.

Comment 1 Jan Synacek 2017-10-16 07:40:52 UTC
I agree that the message is pretty stupid and bears no useful information for the user.


(In reply to Wayne Pollock from comment #0)
> The issue seems to be that the system does support ICMP sockets ("ping"
> sockets), but by default their use is prohibited in the kernel.
> 
> Work-Around:
> 
> To allow the use of ICMP sockets by ping, you need to enable them for root:
> 
> 1.   # sysctl -w net.ipv4.ping_group_range="0 0"
> 
> (Aside: this is the silliest security mechanism I've come across in Linux.)
> Next, make ping SGID to root:
> 
> 2.  # chmod g+s /usr/bin/ping
> 
> Now ping can use ICMP sockets.

$ getcap /usr/bin/ping 
/usr/bin/ping = cap_net_admin,cap_net_raw+p

In Fedora, capabilities are used, so you don't have to set the group range or the setuid bit (which, in theory, is not safe). For some reason, unknown to me, upstream have decided to create a regular socket first, which, of course, fails when the user doesn't have the right permissions.

Comment 2 Jan Synacek 2017-10-16 07:53:01 UTC
https://github.com/iputils/iputils/pull/107

Comment 3 Wayne Pollock 2017-10-16 09:51:24 UTC
"For some reason, unknown to me, upstream have decided to create a regular socket first..."

I believe the reason is that the kernel since around 2010 that allows the creation of ICMP ECHO sockets without any special permissions or capabilities.  See <https://lwn.net/Articles/420800/>.  This is what ping attempts first (not a regular IP socket).  If this feature is enabled, you don't need SUID or setcap on ping.

However, this feature is controlled by the ping_group_range setting, which is set to completely disabled ("1 0") in Fedora.  Apparently some other distros set this to all GIDs, so ping does not need privileges on those systems.

Since either approach works, I believe your patch to remove the pointless message is an excellent fix.  If however you wish to reduce the number of binaries shipped with elevated privileges, it might be better/safer to enable ping_group_range for all GIDs ("0 2147483648", I think), then see which other binaries no longer would need extra capabilities.

Comment 4 Jan Synacek 2017-10-16 10:12:44 UTC
(In reply to Wayne Pollock from comment #3)
> If however you wish to reduce the number of
> binaries shipped with elevated privileges, it might be better/safer to
> enable ping_group_range for all GIDs ("0 2147483648", I think), then see
> which other binaries no longer would need extra capabilities.

That would be nice, in my opinion. However, this is not for me to decide. I believe that such change would have to be approved by FESCo.

Comment 5 Jan Synacek 2017-10-17 08:32:39 UTC
Merged upstream.

Comment 6 Fedora End Of Life 2018-05-03 08:20:22 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 7 Fedora End Of Life 2018-05-29 12:01:13 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 8 Wayne Pollock 2018-05-30 03:04:47 UTC
Still present if Fedora 28.

Comment 9 Jan Kurik 2018-05-31 09:12:42 UTC
This bug is currently reported against a Fedora version which is already unsuported.
I am changing the version to '27', the latest supported release.

Please check whether this bug is still an issue on the '27' release.
If you find this bug not being applicable on this release, please close it.

Comment 10 Wayne Pollock 2018-05-31 20:56:56 UTC
Confirmed in Fedora 27 and 28.

Comment 11 Ben Cotton 2019-05-02 21:40:15 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Ben Cotton 2019-05-28 20:27:44 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.