Control: reassign -1 src:dpkg Control: severity -1 wishlist > root@debian:~# ls -l `which ping` > -rwxr-xr-x 1 root root 77432 Aug 23 19:08 /usr/bin/ping > root@debian:~# getcap `which ping` > /usr/bin/ping cap_net_raw=ep > root@debian:~# > > > This looks like a limitation that would only be possible to solve by > dpkg and extending tar / cpio probably. > > >From what I found it is possible to do this with tar and > --xattrs-include='security.capability' when packing and unpacking. > > There is some hacky non-standard patches for cpio, > https://github.com/initlove/cpio/commit/531cabc88e9ecdc3231fad6e4856869baa9a91ef > , but afaik not upstreamed. > And even more hacky support in kernel for initramfs uses: > https://lists.gnu.org/archive/html/bug-cpio/2019-05/msg00001.html > > I didn't see any real updates on this topic, last one is from middle of 2019.
I'm reassigning this to dpkg as a wishlist item. If the problem is going to be fixed, it's going to happen at a layer more fundamental to package management. Context for the dpkg maintainers: Ping requires elevated privileges in order to open its ICMP network sockets. The postinst script attempts to set a file-based cap_net_raw capability on the binary after installation, and falls back to setuid in case that fails (usually due to missing filesystem support for file capabilities). This workflow is racy, however, as there's a period of time when the file exists on disk but has not had any privilege acquisition mechanism applied to it. During this period of time, unprivileged users cannot run this program, when otherwise they could. Elimination of this race situation would likely require the ability for dpkg to initially create files with additional file-based capabilities. noah
