Description of problem: ping fails with "icmp open socket: Operation not permitted" Version-Release number of selected component (if applicable): iputils-20101006-2.fc15.i686 How reproducible: always Steps to Reproduce: 1. ping -c 1 $WHATEVER 2. 3. Actual results: ping: icmp open socket: Operation not permitted Expected results: normal ping output (can't copy/paste richt now) Additional info:
This bug is affected fixing following bug https://bugzilla.redhat.com/show_bug.cgi?id=646444 You should especially pay attention to comment #1. Ping(6) uses no more setuid flag necessary for opening socket. This is replaced by setting capability cap_net_raw. This issue is related to your system because there is missing mentioned capability for opening socket. Could provide more info about your system.
(In reply to comment #1) > Could provide more info about your system. What info would you need?
0) Google pointed me to this article: http://lwn.net/Articles/313047/ 1) Then I played around a bit: $ rpm -q --filecaps iputils /bin/ping = cap_net_raw+ep /bin/ping6 = cap_net_raw+ep /bin/tracepath [...] $ getcap -v /bin/ping /bin/ping $ sudo setcap cap_net_raw=ep /bin/ping $ getcap -v /bin/ping /bin/ping = cap_net_raw+ep $ ping -c 1 bugzilla.redhat.com PING bugzilla.redhat.com (209.132.183.69) 56(84) bytes of data. 64 bytes from bugzilla.redhat.com (209.132.183.69): icmp_req=1 ttl=116 time=166 ms --- bugzilla.redhat.com ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 166.330/166.330/166.330/0.000 ms 2) It seems that somehow: - rpm thinks capabilities are set on ping and ping6 - capabilities weren't actually set on those binaries Does that make sense?
I see the same here. On 3 different machines but all have been updated from f14-beta. Btw. rootfs are ext4 and btrfs so this shouldn't be the problem.
(In reply to comment #3) > 2) It seems that somehow: > - rpm thinks capabilities are set on ping and ping6 > - capabilities weren't actually set on those binaries > > Does that make sense? Note that rebuilding the iputils rpm doesn't seem to trigger a call of setcap, even though these lines are to be found in the specfile: %attr(0755,root,root) %caps(cap_net_raw=ep) /bin/ping [...] %attr(0755,root,root) %caps(cap_net_raw=ep) /bin/ping6 But should setcap actually be invoked by rpmbuild?
Well, thanks for very useful info. If I understood comment #3 correctly rpm don't message any problem with setting capability during update process and also querying don't detect any problem. This is due to searching for capability in rpmdb without real verifying. Usage rpm verify probably will discover missing capability as well as getcap. You was successful with manual setting capability and ping works as expected. Therefore I'm going to switch the bug against rpm.
I think the problem might be prelink. prelink seems to be blowing away file capabilities.
(In reply to comment #7) > I think the problem might be prelink. prelink seems to be blowing away file > capabilities. Well, at least my suggestion in comment #5 that rpmbuild doesn't use setcap (or a similar procedure) was incorrect (or irrelevant). After actually _installing_ a locally rebuilt iputils rpm, the capabilities were somehow correctly set on /bin/ping and /bin/ping6.
Run prelink on them and I bet the capabilities will disappear.
(In reply to comment #9) > Run prelink on them and I bet the capabilities will disappear. $ getcap /bin/ping /bin/ping = cap_net_raw+ep $sudo prelink /bin/ping $ getcap /bin/ping6 /bin/ping6 = cap_net_raw+ep $ sudo prelink /bin/ping6 $ getcap /bin/ping6 $ Your bet is correct.
Some copy/paste errors above, but the bet's still correct.
Update component and summary.
*** This bug has been marked as a duplicate of bug 456105 ***