Bug 1666284

Description of problem:

Until recently it was not safe to use fcaps in unprivileged containers, but starting with Linux kernel version 4.14 it is possible to set fcaps in user namespaces.
This is something that is really useful for unprivileged containers.

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

Karsten, I am trying to test it properly and here is what I got:

# rpm -q kernel libcap
kernel-4.18.0-128.el8.x86_64
libcap-2.26-1.el8.x86_64

# useradd testuser

# id testuser 
uid=1000(testuser) gid=1000(testuser) groups=1000(testuser)

# mkdir /tmp/foo

# cp /usr/bin/ping /tmp/foo

# getcap -vn /tmp/foo/ping
/tmp/foo/ping

# su -c '/tmp/foo/ping -c 3 127.0.0.1' -- testuser
ping: socket: Operation not permitted

# setcap cap_net_raw+eip /tmp/foo/ping 

# getcap -vn /tmp/foo/ping
/tmp/foo/ping = cap_net_raw+eip

# su -c '/tmp/foo/ping -c 3 127.0.0.1' -- testuser
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.041 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.040 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 63ms
rtt min/avg/max/mdev = 0.023/0.034/0.041/0.010 ms

# setcap -r /tmp/foo/ping 

# setcap -n 1000 cap_net_raw+eip /tmp/foo/ping 

# getcap -vn /tmp/foo/ping;
/tmp/foo/ping = cap_net_raw+eip [rootid=1000]

# su -- testuser

$ unshare --map-root-user --user /bin/bash

# cat /proc/self/uid_map 
         0       1000          1

# getcap -vn /tmp/foo/ping
/tmp/foo/ping = cap_net_raw+eip

# /tmp/foo/ping -c 3 127.0.0.1
ping: socket: Operation not permitted

Am I doing something wrong? User testuser is mapped to root in created user namespace. Capability cap_net_raw is set to be used only in namespace owned by testuser. Using getcap from that user namespace shows that all is set correctly. But when /tmp/foo/ping is used from namespace operation is not permitted even though it should be. Or did I get it wrong?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:3539