If you don't need root to run it, don't install it in */sbin/.

Packages are installed into /usr/bin and /usr/sbin.

Locally-built software (e.g. `./configure --prefix=/; make; make install`) is installed into /usr/local/bin and /usr/local/sbin, which should still always require elevated privileges to write to.

~/.local/bin is convenient but dangerous, because a process should not be able to overwrite itself on disk (unless the user has allowed it to auto-update itself, instead of using a package manager with out-of-band public key retrieval)

This is all probably in the discussions,

A. "Audit all binaries run as root" (TODO lookup the probably CIS control URL for this; look for disk-resident programs that run with elevated privileges)

A.1. Find setuid and setgid files:

      sudo \
        find /  -type f \( -perm -4000 -o -perm -2000 \) -exec ls -ld '{}' \; \
        2> find-setuid.errors \
        > find-setuid.files

A.2. Find setcap binaries

A.3. Find extended filesystem attribute permissions with e.g. getfacl

A.4. List everything in */sbin that only root users should need to run (*)

A.5. Find everything that's `chown root; chmod o-x`;

(When you remove the e(x)ecute bit from a directory, that user/group/other can't list the files in the directory; which is logged to stderr when e.g. `find`

Nowadays we can just do the SBOM tool on everything in every */?bin direcotry and just check those

If "merge sbin into bin" isn't already changed in the FHS spec, I'm -0 to -1 on the idea and don't see really any benefits.

Filesystem Hierarchy Standard: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Disadvantage: Users would inadvertantly exec() programs they don't need to run log exec()s of, if /sbin and /bin are merged; there will be more binary enumeration log messages to parse.

Disadvantage: Other distros won't merge /sbin and /bin, so the paths in log messages in support issues and mailing lists would be less universally searchable