Re: Ping as normal user (Was: Why /usr/sbin is not in my root $PATH ?)
Hi,
i wrote:
> > "d/control: Drop Priority of libcap2"
> > https://salsa.debian.org/debian/libcap2/commit/5386335db24bfff5cc85bda69dbcda6ab2d7d20d
Reco wrote:
> Ah, that's what is was. That change made into the stable, I've just checked.
Not according to the package tracker:
oldstable has 1:2.24-8 of march 2015, i.e. before bug 780721.
https://tracker.debian.org/media/packages/libc/libcap2/control-1%3A2.24-8
No particular Priority set on lbibcap2-bin
stable has 1:2.25-1 of october 2017, i.e. after bug 780721 went to sleep.
https://tracker.debian.org/media/packages/libc/libcap2/control-1%3A2.25-1
libcap2-bin gets "Priority: important".
testing has 1:2.25-2 of february 2019.
https://tracker.debian.org/media/packages/libc/libcap2/control-12.25-2
libcap2-bin still gets "Priority: important".
It was accepted in unstable at the very same day as the commit was made
which removed the particular Priority in the salsa git repo.
The package tracker's source browser says it is still in:
https://sources.debian.org/src/libcap2/1:2.25-2/debian/control/#L17
But not to forget, the packages on the Debian mirrors get their priority
from the uploading procedure, not necessarily from the debian/control file
or the derived .dsc file.
All this forth and back might be independent of the maintainer of libcap2.
> Not every filesystem supported by Debian
> implements extended attributes needed for capabilities.
> Off the top of my head it's NFS and JFFS2.
It is about the filesystem which holds the /bin directory. I would deem it
extra-expert to use a partly incapable filesystem for that.
Whatever, the maintainer's reasoning was a then valid quote from the
policy manual
"Packages must not depend on packages with lower priority values
(excluding build-time dependencies). In order to ensure this, the
priorities of one or more packages may need to be adjusted."
which is now replaced by a contrary statement
"The priority of a package should
not be increased merely because another higher-priority package depends
on it; instead, the tools used to construct Debian installations will
correctly handle package dependencies. In particular, this means that
C-like libraries will almost never have a priority above optional [...]"
The issue of incapable systems was addressed in bug 780721 by maintainer:
"The iputils-ping postinst script takes care to handle the case where
setcap is either not available or not functional (due e.g. to running on
a filesystem that doesn't support capabilities."
and bug reporter:
"I'm aware we can't use capabilities on the non-Linux kernels yet, but
since dpkg allows us to set dependencies per arch or per kernel, I don't
see any particular problem adding libcap2-bin as to Depends for Linux."
It became not a decisive argument against dependency.
> Upgrading this particular dependency leads
> only to a dependency bloat, and Default Users™ (i.e. ones that are
> installing Recommends by default) aren't affected anyway.
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.
To skip a security improvement in order to save 111 kB of installed size
seems daring. (Size for amd64 taken from end of
https://packages.debian.org/unstable/libcap2-bin
)
We can expect that the bug reporter, who is working on a colorful bunch
of elderly CPU arches, has a different idea of a Default User than us.
But shortage of memory and disk capacity surely belong to his considerations.
Have a nice day :)
Thomas
Reply to: