Hi, i wrote: > > Currently the Default User depends on assumptions about local package > > management which are not obviously related to security. > > That's a future pitfall which just needs its unintentional cover removed.
Reco wrote: > The way I see it, the "problematic" package got that Important priority > already. A potential pitfall is closed. The priority in debian/control (and thus .dsc) is scheduled on salsa to be lowered to "optional" by the next package release. Whatever, the priority is not the problem with security. The lack of dependency of iputils-ping on libcap2-bin is the problem. This lack was justified by policy as of 2016. Soon later the priority of libcap2-bin was raised to "important", but iputils-ping never made use of this move. > Replacing a working fallback mechanism with one-size-fits-all "everyone > are using ext4 on amd64 and Linux" is hardly an improvement. The proposal in the bug report would not disable the fallback mechanism for situations where it is needed. It would only make sure that capable kernels and filesystems would be able use upstream improvements of iptools. The installation code in https://sources.debian.org/src/iputils/3:20180629-2/debian/iputils-ping.postinst adapts itself to effective success of an attempt to set capabilities: if command -v setcap > /dev/null; then if setcap cap_net_raw+ep /bin/ping; then chmod u-s /bin/ping else echo "Setcap failed on /bin/ping, falling back to setuid" >&2 chmod u+s /bin/ping fi else echo "Setcap is not installed, falling back to setuid" >&2 chmod u+s /bin/ping fi Safe for Default Users. My best theory for the problem reported in bug 780721 that a normal user cannot ping, is that setuid was disabled by mount -o nosuid or -o owner and that setcap did not work because of his sparse installation. Have a nice day :) Thomas
