Bug 1194156

Similar:
(2137/5706) Installing: gstreamer-1.16.3-3.3.1.x86_64 ....[done]
Additional rpm output:
setting /usr/lib/gstreamer-1.0/gst-ptp-helper to root:root 0755 "= cap_net_bind_service+ep". (wrong missing capabilities)

Reading it again, it may seem that what I thought is an error message ("wrong missing capabilities") actually is a success message ("added missing capability").
Am I right?

Reassigning to openSUSE maintainers of package iputils.

Marcus, Petr, could you please help us? In case that not, do not hesitate to reassign back.

Thanks for consideration

Also adding gnome-bugs@suse.de for gstreamer.

Can you use pin

Can you actually use ping as user? 

$ ping -c1 ::1; echo $?
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.057 ms

--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.057/0.057/0.057/0.000 ms
0

Also, due #1174504 you should not need any capability:
$ getcap `which ping` # nothing

(In reply to Petr Vorel from comment #8)
> Can you actually use ping as user? 

Yes, I can.

> Also, due #1174504 you should not need any capability:
> $ getcap `which ping` # nothing

I don't have a "getcap" utility here:
 which getcap
which: no getcap in (/home/windl/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin)

(In reply to Ulrich Windl from comment #9)
> I don't have a "getcap" utility here:
>  which getcap
> which: no getcap in
> (/home/windl/bin:/usr/local/bin:/usr/bin:/bin:/usr/lib/mit/sbin)

Please install libcap-progs.

Thank you Petr you are looking into, much appreciated.

Well, I do understand of iputils background (I'm an upstream maintainer).

But I'm not really the expert on openSUSE packaging and upgrading (I use Tumbleweed myself), thus I'm not sure how I can help.

Although version in Tumbleweed does not require CAP_NET_RAW since last year
(https://build.opensuse.org/request/show/840044 and #1174504), Leap 15.3 inherits quite old version s20161105, where we still used CAP_NET_RAW instead of ICMP_PROTO (although ICMP_PROTO is supported by kernel thus it could be used).

But I guess this error is due using cap_net_raw+ep instead of just cap_net_raw+p.
See related bug #1140993 and change in Tumbleweed in "Fri Jul 26 06:19:44 UTC 2019":

- With new permissions package both clockdiff and ping have capabilities
  cap_net_raw+p instead of cap_net_raw+ep (boo#1140993), also ping6 does not
  try to set permissions on links (boo#1140991)

Thanks, Petr.

15.3 inherites the version from SUSE:SLE-15:Update. I can certainly help with packaging, however I am not completely sure what are you exactly proposing to do. 

Do you think we should update iputils in 15.3 update channel? Isn't that too risky? In case it is easy, perhaps we could consider to update it in 15sp4?

Or other way around?

First, after confirming with Matthias Gerstner the "wrong missing capabilities" message is not a bug, just info. Thus closing bug as invalid.

He also suggested to backport just to 15.4. I suppose updating SLE 15.4 (with changes from #1140993 and #1140991 if not already merged) should work, Leap should then get the fix from update.

(In reply to Petr Vorel from comment #14)
> First, after confirming with Matthias Gerstner the "wrong missing
> capabilities" message is not a bug, just info. Thus closing bug as invalid.
> 
> He also suggested to backport just to 15.4. I suppose updating SLE 15.4
> (with changes from #1140993 and #1140991 if not already merged) should work,
> Leap should then get the fix from update.

Thanks for suggestions, in case I should submit something somewhere, feel free to let me know.

(In reply to Petr Vorel from comment #14)
> First, after confirming with Matthias Gerstner the "wrong missing
> capabilities" message is not a bug, just info. Thus closing bug as invalid.

I had suspected that already in comment #2. However the phrase "wrong missing ..." sounds much more like an error rather than a warning message.
Maybe re-phrase the message into something like "added missing capability/capabilities ...".

(In reply to Ulrich Windl from comment #18)
> (In reply to Petr Vorel from comment #14)
> > First, after confirming with Matthias Gerstner the "wrong missing
> > capabilities" message is not a bug, just info. Thus closing bug as invalid.
> 
> I had suspected that already in comment #2. However the phrase "wrong
> missing ..." sounds much more like an error rather than a warning message.
> Maybe re-phrase the message into something like "added missing
> capability/capabilities ...".

For what it's worth, this came from permissions-20181225/chkstat.c, in Tumbleweed it is */src/chkstat.cpp with quite a lot of rewritten code.

(In reply to pgajdos@suse.com from comment #19)
> (In reply to Ulrich Windl from comment #18)
> > (In reply to Petr Vorel from comment #14)
> > > First, after confirming with Matthias Gerstner the "wrong missing
> > > capabilities" message is not a bug, just info. Thus closing bug as invalid.
> > 
> > I had suspected that already in comment #2. However the phrase "wrong
> > missing ..." sounds much more like an error rather than a warning message.
> > Maybe re-phrase the message into something like "added missing
> > capability/capabilities ...".
> 
> For what it's worth, this came from permissions-20181225/chkstat.c, in Tumbleweed it is */src/chkstat.cpp with quite a lot of rewritten code.

I agree that the wording is not ideal. The situation with this chkstat tool is
pretty complex, though. It is not only used during package installations but
also possibly interactively (e.g. `chkstat --system`) to restore or change
current permissions. The context in which it is executed is not clear to
chkstat.

See also here [1] for more information. There exist different profiles for
different security flavors.

[1]: https://en.opensuse.org/openSUSE:Security_Documentation#Available_Profiles

I will create an issue in our permissions project to track the problematic
wording, maybe we can still improve upon that.