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).

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

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. permissions (or not). Or whether they need to run cdrecord with higher priority (-> no, it has cap_sys_nice+ep with permissions.easy). Aaron

On Wednesday 2023-08-16 01:18, Aaron Puchert wrote:

Am 15.08.23 um 11:36 schrieb Jan Engelhardt:

...

sbin: "system programs and administration utilities"

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.

sudo is not affected by your PATH. `sudo getcap` still works. Your shell might not see that in tabbing, but that's just one of the many problems with a suid tool in an unprivileged shell, "sudo something >>/etc/protectedfile" being one of those. Just use `sudo bash` and move on.

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.

Just because you can run mkfs.xfs as a normal user does not make it very useful, unless perhaps you are trying to debug xfsprogs itself. It's just nowhere near the commonality of /bin/ls.

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.

Yes, change your PATH if you think that is useful for your case. Or do the experiment on yourself and just type out /usr/sbin/ in front and then count how often you needed it. With UsrMerge, you can now just use /sbin (less typing).

Am 16.08.23 um 10:02 schrieb Jan Engelhardt:

On Wednesday 2023-08-16 01:18, Aaron Puchert wrote:

...

Am 15.08.23 um 11:36 schrieb Jan Engelhardt:

...

sbin: "system programs and administration utilities" 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. sudo is not affected by your PATH. `sudo getcap` still works. Of course, but getcap doesn't need sudo. I want to run it without typing in some password. Just use `sudo bash` and move on. Works well of course (or `sudo su`), but removes the audit trail. I'm still using root shells occasionally, but mostly for working in non-world-readable directories. 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. Yes, change your PATH if you think that is useful for your case. Or do the experiment on yourself and just type out /usr/sbin/ in front and then count how often you needed it.

Surely not every day. But I've found myself checking capabilities often enough to warrant a shortcut. There are two other commands from /sbin that I've run occasionally as non-root since setting up compressed swap: `swapon -s` and `zramctl`. But that was mostly out of curiosity.

With UsrMerge, you can now just use /sbin (less typing). Good point, that makes it a bit shorter at least.