Am 15.08.23 um 11:21 schrieb xtexChooser--- via openSUSE Factory:
Recently, I noticed that the `getcap` program in the `libcap-progs` package is packaged into `/usr/sbin/` directory. However, this program works without root permission. Is this an expected behaviour? or should it be moved?
I've wondered about this as well, and after getting annoyed of typing /usr/sbin/getcap I created /usr/local/bin/getcap -> /usr/sbin/getcap. Am 15.08.23 um 11:36 schrieb Jan Engelhardt:
sbin: "system programs and administration utilities"
getcap (or e.g. sysctl) is hardly useful for normal users because of the privileged nature of making modifications with setcap (or sysctl -w).
That was the idea in the early UNIX days, but it's becoming unusual to log in as root, and administrative work is mostly done from regular accounts with the occasional use of sudo. Because even as an admin, there is a bunch of things you might not want to run as root. So while getcap is certainly an administrative tool, it doesn't (ever?) require additional capabilities, so there is (never?) a need to run it as root. Similarly, other "privilege escalation data" is also shown by unprivileged tools, like the {S,G}UID bits. Similarly, you're probably going to run /usr/bin/ip -> ../sbin/ip with your administrative hat on most of the time, but you'll still appreciate that it sits in your non-root PATH and allows you to view the configuration easily. Alternatively, would you suggest an "administrator" add /usr/sbin to their PATH for the tools that don't actually need privileges? But many of us are effectively administrators these days.
Normal users don't use it, except perhaps to learn a bit about intricate system details, which is not normal enough for /bin. The user might also want to learn why a tool requires additional permissions (or not). Or whether they need to run cdrecord with higher priority (-> no, it has cap_sys_nice+ep with permissions.easy).
Aaron