make ping executable by normal users?

[Britton Kerin]

On my old debian system I could ping as a normal user. The ping
binary had the suid bit set. Now I get:

$ ping www.google.com
ping: icmp open socket: Operation not permitted
2 $

presumably because the bit isn't set.

What's the right fix? I could setuid it but then if I understand
correctly it might get changed back by an upgrade. Does it use
capabilites or something?

Thanks,
Britton

[Lisi Reisz]

So far as I can see, ping IS executable by normal users. But then I have only
got Wheezy and Jessie. Are you using Stretch or Sid??

Lisi

[Santiago Vila]

Yes, it uses capabilities. The simple fix is to do this:

dpkg-reconfigure iputils-ping

[Santiago Vila]

On Thu, Jun 02, 2016 at 11:28:40PM +0100, Lisi Reisz wrote:

> So far as I can see, ping IS executable by normal users. But then I have only
> got Wheezy and Jessie. Are you using Stretch or Sid??

This is not really new in stretch. You can experiment this funny
effect in jessie as well. Try this on a jessie system:

cd /bin
mv ping ping.old
cp ping.old ping

Then ping will no longer work for an ordinary user because it lost its
"capability", that you can see with getcap this way:

getcap ping.old
getcap ping

It's a funny effect because you will never see the difference by just
doing "ls -l".

This capability may be lost, for example, if you use rsync to copy the root
filesystem to another partition with rsync and forget to use -X option.

[Mark Fletcher]

Operation not permitted doesn't, contrary to appearances, automatically mean a permissions problem. I recently built a Linux From Scratch machine and at one point was getting that error when running ping as root. I'm now wracking my brains to remember what the cause was.

Could you have a local firewall eg iptables that has accidentally blocked ALL outgoing traffic? I think you can get this error if ping cannot connect OUT of the box.

Does it happen if you run ping as root?

I've also seen this when the kernel didn't have all the right stuff compiled in, but that's not likely to be it if you are using a Debian kernel. Running strace on a ping attempt could diagnose that.

So check if it happens when you are root. If it does, check your internal firewall (not your network's). If that is ok or switched off, try strace.

Mark

[Jan Bakuwel]

Hi Britton,

This is not you not being able to execute ping but ping not being able
to ping.

Check your firewall rules.

cheers,
Jan

[Norbert Kiszka]

Dnia 2016-06-06, pon o godzinie 10:06 +1200, Jan Bakuwel pisze:

Yep. Give us result of: iptables -L

[Santiago Vila]

On Mon, Jun 06, 2016 at 10:06:54AM +1200, Jan Bakuwel wrote:
> Check your firewall rules.

It can't be firewall rules. Try this to block outgoing ping:

iptables -A OUTPUT -p icmp --icmp-type echo-request -j REJECT

then try to ping anywhere. You will get a different error message,
namely "Destination Port Unreachable".

[ Why people do not read all messages in the thread before answering
is a mystery to me ].

Thanks.

[Mark Fletcher]

No, that's not true, you definitely can get this very error due to something to do with the firewall, maybe it's not able to resolve the ping target rather than not able to reach the resulting host, I'm damned if I can remember the specifics but I've definitely seen this happen on an lfs box before and it was nothing to do with perms (as I said before, to your point about people not reading the whole thread...)

Mark

[Reco]

Hi.

On Mon, Jun 06, 2016 at 03:57:47PM +0200, Santiago Vila wrote:
> On Mon, Jun 06, 2016 at 10:06:54AM +1200, Jan Bakuwel wrote:
> > Check your firewall rules.
>
> It can't be firewall rules. Try this to block outgoing ping:
>
> iptables -A OUTPUT -p icmp --icmp-type echo-request -j REJECT
>
> then try to ping anywhere. You will get a different error message,
> namely "Destination Port Unreachable".

But if you transform the rule in question a little, like this:

iptables -I OUTPUT -p icmp --icmp-type echo-request \
-j REJECT --reject-with icmp-admin-prohibited

ping will respond with 'Operation not permitted'. An exact wording of the
message seems to depend on actual ping implementation.

So, checking firewall rules is a valid advice. It's just this particular
problem happens due to lack of file capabilities.

Reco

[David Wright]

On Mon 06 Jun 2016 at 15:27:16 (+0000), Mark Fletcher wrote:
> On Mon, 6 Jun 2016 at 23:15, Santiago Vila <san...@unex.es> wrote:
>
> > On Mon, Jun 06, 2016 at 10:06:54AM +1200, Jan Bakuwel wrote:
> > > Check your firewall rules.
> >
> > It can't be firewall rules. Try this to block outgoing ping:
> >
> > iptables -A OUTPUT -p icmp --icmp-type echo-request -j REJECT
> >
> > then try to ping anywhere. You will get a different error message,
> > namely "Destination Port Unreachable".
> >
> > [ Why people do not read all messages in the thread before answering
> > is a mystery to me ].

> No, that's not true, you definitely can get this very error due to
> something to do with the firewall, maybe it's not able to resolve the ping
> target rather than not able to reach the resulting host, I'm damned if I
> can remember the specifics but I've definitely seen this happen on an lfs
> box before and it was nothing to do with perms (as I said before, to your
> point about people not reading the whole thread...)

I don't understand this argument.

Why would ping bother to open a socket to a host it couldn't resolve?

I know precious little about firewall rules, but AIUI the rules
determine whether to respond with things like Drop, Reject, Deny.
Now the OP didn't manage to open a socket; that's in the error message:

"ping: icmp open socket: Operation not permitted"

So how would ping find out how the firewall was going to react to its
ping message without opening a socket to send something?

Cheers,
David.

[Santiago Vila]

On Mon, Jun 06, 2016 at 03:27:16PM +0000, Mark Fletcher wrote:

> you definitely can get this very error due to something to do with
> the firewall,

Well, you can get this very error if you follow the steps I explained here:

https://lists.debian.org/msgid-search/20160602225...@cantor.unex.es

If you provide a recipe to get that very error with firewall rules,
I will believe that it may be firewall rules, but considering that
most people do not block outgoing ping (most people do not block
outgoing traffic at all), considering that we have a way to reproduce
the exact error, and following Occam's razor, lack of capability is
the most likely reason.

Thanks.

[Norbert Kiszka]

Dnia 2016-06-06, pon o godzinie 11:00 -0500, David Wright pisze:

Did You change linux kernel, kernel modules or something lastly?

Show output of lsmod.

[David Wright]

# iptables -I OUTPUT -p icmp --icmp-type echo-request -j REJECT --reject-with icmp-admin-prohibited

$ ping alum.local
PING alum.local (192.168.1.19) 56(84) bytes of data.
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
>From 192.168.1.15 icmp_seq=1 Packet filtered
ping: sendmsg: Operation not permitted
ping: recvmsg: No route to host
ping: recvmsg: No route to host
ping: recvmsg: No route to host
ping: recvmsg: No route to host
ping: recvmsg: No route to host
[ad infinitum]

[reboot]

Cheers,
David.

[David Wright]

> Did You change linux kernel, kernel modules or something lastly?

I now know even less about what you're talking about. I don't have a
problem. I have easily duplicated the OP's error message in the
following way:

$ cp -ip /bin/ping /tmp
$ /tmp/ping alum.local

ping: icmp open socket: Operation not permitted

$ /sbin/getcap /tmp/ping
$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep
$

That's jessie. On wheezy:

$ ls -l /bin/ping /tmp/ping
-rwsr-xr-x 1 root root 31104 Apr 12 2011 /bin/ping
-rwxr-xr-x 1 david david 31104 Apr 12 2011 /tmp/ping

Cheers,
David.

[Reco]

As I wrote earlier - it depends on the implementation of a ping. For me
it looks like this:

$ dpkg -S $(which ping)
iputils-ping: /bin/ping
$ ping -c2 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.

ping: sendmsg: Operation not permitted

ping: sendmsg: Operation not permitted
<long hang>
^C
--- localhost ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1007ms

Reco

[David Wright]

But the OP's error message was

"ping: icmp open socket: Operation not permitted"

and not

"ping: sendmsg: Operation not permitted"

Cheers,
David.

[Norbert Kiszka]

Dnia 2016-06-06, pon o godzinie 11:26 -0500, David Wright pisze:

Show output of those commands:

# iptables -L
# lsmod
$ uname -a
$ cat /etc/issue

[David Wright]

> Show output of those commands:
>
> # iptables -L
> # lsmod
> $ uname -a
> $ cat /etc/issue

Gladly, though I think you're taking an unhealthy interest in *my* machine.

# /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
#

Bear in mind that I rebooted after making the change posted in this thread,
so that change is lost.

$ lsmod
Module Size Used by
iptable_filter 12488 0
ip_tables 16975 1 iptable_filter
x_tables 17978 2 ip_tables,iptable_filter
ctr 12807 2
ccm 17361 2
snd_hrtimer 12540 1
snd_seq_midi 12744 0
snd_seq_midi_event 13124 1 snd_seq_midi
snd_rawmidi 22372 1 snd_seq_midi
snd_seq 51562 3 snd_seq_midi_event,snd_seq_midi
snd_seq_device 12980 3 snd_seq,snd_rawmidi,snd_seq_midi
bnep 17184 2
cpufreq_powersave 12422 0
cpufreq_userspace 12477 0
cpufreq_conservative 13872 0
cpufreq_stats 12694 0
nfsd 236959 2
auth_rpcgss 45765 1 nfsd
oid_registry 12387 1 auth_rpcgss
nfs_acl 12463 1 nfsd
nfs 168022 0
lockd 73443 2 nfs,nfsd
fscache 44782 1 nfs
sunrpc 211341 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl
joydev 16847 0
ecb 12649 1
btusb 25417 0
bluetooth 340064 21 bnep,btusb
6lowpan_iphc 16548 1 bluetooth
iTCO_wdt 12727 0
iTCO_vendor_support 12585 1 iTCO_wdt
snd_hda_codec_idt 48266 1
snd_hda_codec_generic 58021 2 snd_hda_codec_idt
arc4 12480 2
dell_wmi 12437 0
sparse_keymap 12730 1 dell_wmi
tg3 154678 0
iwl3945 53405 0
iwlegacy 53921 1 iwl3945
mac80211 425575 2 iwl3945,iwlegacy
snd_hda_intel 26023 0
ptp 17462 1 tg3
coretemp 12708 0
pps_core 17080 1 ptp
libphy 27468 1 tg3
snd_hda_controller 26262 1 snd_hda_intel
sdhci_pci 17697 0
snd_hda_codec 93797 4 snd_hda_codec_idt,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller
cfg80211 350041 3 iwl3945,iwlegacy,mac80211
sdhci 34721 1 sdhci_pci
kvm 330411 0
pcmcia 44245 0
dell_laptop 16941 0
mmc_core 91803 2 sdhci,sdhci_pci
yenta_socket 38561 0
snd_hwdep 12906 1 snd_hda_codec
rfkill 18387 5 cfg80211,bluetooth,dell_laptop
psmouse 93505 0
snd_pcm_oss 44124 0
firewire_ohci 34856 0
dcdbas 13087 1 dell_laptop
pcmcia_rsrc 17292 1 yenta_socket
sg 25573 0
i2c_i801 16845 0
serio_raw 12737 0
snd_mixer_oss 21822 1 snd_pcm_oss
lpc_ich 16616 0
mfd_core 12537 1 lpc_ich
pcmcia_core 18024 3 pcmcia,pcmcia_rsrc,yenta_socket
uhci_hcd 38948 0
snd_pcm 78128 4 snd_pcm_oss,snd_hda_codec,snd_hda_intel,snd_hda_controller
shpchp 30673 0
ehci_pci 12464 0
tpm_tis 17063 0
snd_timer 26105 3 snd_hrtimer,snd_pcm,snd_seq
snd 55101 13 snd_pcm_oss,snd_hwdep,snd_timer,snd_hda_codec_idt,snd_pcm,snd_seq,snd_rawmidi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_mixer_oss
rng_core 12645 0
ehci_hcd 64933 1 ehci_pci
tpm 26879 1 tpm_tis
usbcore 171098 4 btusb,uhci_hcd,ehci_hcd,ehci_pci
usb_common 12408 1 usbcore
soundcore 12890 2 snd,snd_hda_codec
wmi 17147 1 dell_wmi
evdev 17136 4
battery 13164 0
ac 12627 0
acpi_cpufreq 17050 0
processor 27590 3 acpi_cpufreq
binfmt_misc 12733 1
loop 21987 0
firewire_sbp2 17533 0
firewire_core 51113 2 firewire_ohci,firewire_sbp2
crc_itu_t 12331 1 firewire_core
fuse 77496 1
parport_pc 26004 0
ppdev 16686 0
lp 12766 0
parport 35213 3 lp,ppdev,parport_pc
autofs4 34865 2
ext4 438464 3
crc16 12327 2 ext4,bluetooth
mbcache 17027 1 ext4
jbd2 72964 1 ext4
sd_mod 43684 5
crc_t10dif 12399 1 sd_mod
crct10dif_generic 12517 1
crct10dif_common 12340 2 crct10dif_generic,crc_t10dif
ata_generic 12450 0
ata_piix 29371 4
libata 161908 2 ata_generic,ata_piix
scsi_mod 164132 4 sg,libata,sd_mod,firewire_sbp2
i915 762655 1
i2c_algo_bit 12647 1 i915
drm_kms_helper 44450 1 i915
video 17763 1 i915
thermal 17343 0
button 12824 1 i915
drm 207686 3 i915,drm_kms_helper
i2c_core 36838 5 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit
thermal_sys 27122 3 video,thermal,processor
$

Why root?

$ uname -a
Linux west 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux
$ cat /etc/issue
Debian GNU/Linux 8 \n \l

$

I don't think you'll learn much from that lot, but happy to oblige.

Cheers,
David.

[Norbert Kiszka]

Dnia 2016-06-06, pon o godzinie 12:00 -0500, David Wright pisze:

1. Did You tried another kernel? If not, maybe try from backports for first.

2. iptable_filter 12488 0
> ip_tables 16975 1 iptable_filter

Little suspicious for me. What needs this modules when you have default "no rules"?

BTW. You are using wifi currently? Ping to localhost doesnt works too?

[David Wright]

On Mon 06 Jun 2016 at 19:50:55 (+0200), Norbert Kiszka wrote:
> 1. Did You tried another kernel? If not, maybe try from backports for first.
>
> 2. iptable_filter 12488 0
> > ip_tables 16975 1 iptable_filter
>
> Little suspicious for me. What needs this modules when you have default "no rules"?
>
> BTW. You are using wifi currently? Ping to localhost doesnt works too?

I think you need to read back through the thread and see *who* has *what* problem.
I'm perfectly happy with the behaviour of ping on all my machines.
Seem like Santiago Vila was correct in https://lists.debian.org/debian-user/2016/06/msg00235.html!

Cheers,
David.

[Norbert Kiszka]

Dnia 2016-06-06, pon o godzinie 14:04 -0500, David Wright pisze:

mea culpa [:cry:]

[Reco]

Yes, and "aptitude search '~nping'" shows 41 result for me (42 actually
if you count busybox).
I'm somewhat lazy to test each and every implementation of ping to check
which one fails in 'icmp open socket' instead of 'sendmsg'.

So, my point is - it's entirely possible to get EPERM in ping by
misconfiguring iptables. I agree that it's also possible to get EPERM in
ping by denying it CAP_NET_RAW capability.

Reco

[Nicolas George]

Le decadi 20 prairial, an CCXXIV, Reco a écrit :

> Yes, and "aptitude search '~nping'" shows 41 result for me (42 actually
> if you count busybox).
> I'm somewhat lazy to test each and every implementation of ping to check
> which one fails in 'icmp open socket' instead of 'sendmsg'.
>
> So, my point is - it's entirely possible to get EPERM in ping by
> misconfiguring iptables.

No, it is not. There is no need to painstakingly try every single
implementation of ping: some people here know how to actually implement
ping, they know what the various system calls do and how they interact with
firewall rules and network error feedback. And based on that knowledge, they
can tell you: EPERM can be caused by firewall rules on the sendmsg() system
call, but not on the socket() system call, and the original error message
states it happens on the socket() system call.

Note that nobody blames you for not knowing that, it is not a mandatory
knowledge for using Debian, and I am sure there are other things you know
about Debian that few other people know. But try to get the feel of the wind
and understand that, lacking the corresponding knowledge, you should take
their word for it.

Regards,

--
Nicolas George

[Britton Kerin]

Well, that works, thanks. But I really don't get the overall behavior.
It says this:

root@debian:/home/bkerin# dpkg-reconfigure iputils-ping
Setcap worked! Ping(6) is not suid!
root@debian:/home/bkerin#

And then ping works for non-root users.

How, just by executing dpkg-reconfigure, did I tell it this is what
I wanted? If that's the default, why wasn't it that way to begin with?

More generally, is it somehow possible to still run debian without
capabilities? I hate them. The simple root-or-not security model
is much simpler and doesn't promise more than it can really
deliver. I'm sad to see capabilities now as the default.

Britton

[David Wright]

On Tue 07 Jun 2016 at 14:56:11 (-0800), Britton Kerin wrote:
> On Thu, Jun 2, 2016 at 2:33 PM, Santiago Vila <san...@unex.es> wrote:
> > On Thu, Jun 02, 2016 at 01:56:08PM -0800, Britton Kerin wrote:
> >> On my old debian system I could ping as a normal user. The ping
> >> binary had the suid bit set. Now I get:
> >>
> >> $ ping www.google.com
> >> ping: icmp open socket: Operation not permitted
> >> 2 $
> >>
> >> presumably because the bit isn't set.
> >>
> >> What's the right fix? I could setuid it but then if I understand
> >> correctly it might get changed back by an upgrade. Does it use
> >> capabilites or something?
> >
> > Yes, it uses capabilities. The simple fix is to do this:
> >
> > dpkg-reconfigure iputils-ping
>
> Well, that works, thanks. But I really don't get the overall behavior.
> It says this:
>
> root@debian:/home/bkerin# dpkg-reconfigure iputils-ping
> Setcap worked! Ping(6) is not suid!
> root@debian:/home/bkerin#
>
> And then ping works for non-root users.
>
> How, just by executing dpkg-reconfigure, did I tell it this is what
> I wanted? If that's the default, why wasn't it that way to begin with?

dpkg-reconfigure runs /var/lib/dpkg/info/foo.postinst for package foo,
so take a look and you'll see the possibilities.

I've no idea how your ping missed the process, unless it's been copied
incorrectly at some point (though one might expect more problems than
just ping in that case).

> More generally, is it somehow possible to still run debian without
> capabilities? I hate them. The simple root-or-not security model
> is much simpler and doesn't promise more than it can really
> deliver. I'm sad to see capabilities now as the default.

No idea. I'm convinced, rightly or wrongly, by the added fine-grain
security provided by capabilities.

Cheers,
David.

[Santiago Vila]

On Tue, Jun 07, 2016 at 02:56:11PM -0800, Britton Kerin wrote:

> How, just by executing dpkg-reconfigure, did I tell it this is what
> I wanted? If that's the default, why wasn't it that way to begin with?

AFAIK, the tar file format, on which the .deb package format is based,
does not allow for capabilities to be stored inside a tar file, so the
capability has to be set in the postinst and may not be "just there"
after unpacking the package.

Of course, this does not explain why you lost the capability, it would
only explain why the postinst fixes it.

[Adam Borowski]

On Tue, Jun 07, 2016 at 02:56:11PM -0800, Britton Kerin wrote:
> On Thu, Jun 2, 2016 at 2:33 PM, Santiago Vila <san...@unex.es> wrote:
> > On Thu, Jun 02, 2016 at 01:56:08PM -0800, Britton Kerin wrote:
> >> On my old debian system I could ping as a normal user. The ping
> >> binary had the suid bit set. Now I get:
> >>
> >> $ ping www.google.com
> >> ping: icmp open socket: Operation not permitted
> >> 2 $
> >>
> >> presumably because the bit isn't set.
> >

> > Yes, it uses capabilities. The simple fix is to do this:
> >
> > dpkg-reconfigure iputils-ping
>
> Well, that works, thanks. But I really don't get the overall behavior.
> It says this:
>
> root@debian:/home/bkerin# dpkg-reconfigure iputils-ping
> Setcap worked! Ping(6) is not suid!
> root@debian:/home/bkerin#
>
> And then ping works for non-root users.
>
> How, just by executing dpkg-reconfigure, did I tell it this is what
> I wanted? If that's the default, why wasn't it that way to begin with?

It is supposed to work on initial installation as well -- the decision
whether to setcap or setuid is made anew whenever iputils-ping is
configured. Did you do something out of ordinary, like tarring and
restoring or otherwise moving your system around? If so, that's
unfortunately an expected thing -- if not, it'd be nice to know what
else could have failed.

> More generally, is it somehow possible to still run debian without
> capabilities? I hate them.

Yes, apt-get purge libcap2-bin.

This won't undo existing capabilities in the filesystem, you can search for
them with getcap -r, then dpkg --reconfigure them to use setuid instead.

> The simple root-or-not security model is much simpler and doesn't promise
> more than it can really deliver.

Giving only limited capabilities greatly reduces possible attacks. If
someone manages to subvert ping, in the setuid model he gains full root. In
the capability model, all he gets is cap_net_raw. The damage from being
able to create raw sockets is rather limited. Another such capability is
for example cap_net_bind_service which lets your http/whatever server to
listen on port 80 without being root. And so on...

On the other hand, setcap does have its downsides, like surprising some
sysadmins or tools.

> I'm sad to see capabilities now as the default.

I'd say the upside outweights the downsides. But, you do get to choose.


Meow!
--
An imaginary friend squared is a real enemy.

[Ben Hutchings]

On Tue, 2016-06-07 at 14:56 -0800, Britton Kerin wrote:
> On Thu, Jun 2, 2016 at 2:33 PM, Santiago Vila <san...@unex.es> wrote:
> > On Thu, Jun 02, 2016 at 01:56:08PM -0800, Britton Kerin wrote:
> > > On my old debian system I could ping as a normal user.  The ping
> > > binary had the suid bit set.  Now I get:
> > >
> > >     $ ping www.google.com
> > >     ping: icmp open socket: Operation not permitted
> > >     2 $
> > >
> > > presumably because the bit isn't set.
> > >
> > > What's the right fix?  I could setuid it but then if I understand
> > > correctly it might get changed back by an upgrade.  Does it use
> > > capabilites or something?
> >
> > Yes, it uses capabilities. The simple fix is to do this:
> >
> > dpkg-reconfigure iputils-ping
>
> Well, that works, thanks.  But I really don't get the overall behavior.
> It says this:
>
>      root@debian:/home/bkerin# dpkg-reconfigure iputils-ping
>      Setcap worked! Ping(6) is not suid!
>      root@debian:/home/bkerin#
>
> And then ping works for non-root users.
>
> How, just by executing dpkg-reconfigure, did I tell it this is what
> I wanted?  If that's the default, why wasn't it that way to begin with?

It probably was, but see bug #770492.

> More generally, is it somehow possible to still run debian without
> capabilities?

[...]

Capabilities are a non-optional feature of Linux.  There are Debian
ports to other kernels where this may not be the case.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged
demo.

[Santiago Vila]

On Wed, Jun 08, 2016 at 02:44:52PM +0100, Ben Hutchings wrote:
> [...] see bug #770492.

Truly amazing! For "ping", it would be like this:

$ /sbin/getcap /bin/ping
/bin/ping = cap_net_raw+ep

$ chown root:root /bin/ping
chown: changing ownership of '/bin/ping': Operation not permitted
$ /sbin/getcap /bin/ping
[ empty output ]

And you don't even have to be root, so this is a lot easier method to
lose the capability than doing tar + untar or using rsync without -X.

Thanks.