zlacker

For me, the value in having a bin vs sbin split is in keeping system binaries (daemons, root-only tools) off the user's path. There's little value in a user starting inetd or apache2 from the command line, so why should those be present in the user's path? Same thing for system management tools that require root access for everything, such as dmsetup, blkdiscard, or shutdown (yes, Linux examples as I don't know FreeBSD).

Having only usable binaries in the path aids discoverability of the system.

>>tremon+(OP)
> so why should those be present in the user's path

And why shouldn't they?

It's not as if a user could do anything damaging with them, if the system is setup properly.

> Having only usable binaries in the path aids discoverability of the system.

Except when someone new has to go online to ask "I found this tutorial telling me to use the `xyz` command to do this, but all I get is `bash: xyz: command not found`, please help!"

>>tremon+(OP)
There are many tools in sbin that should have been in bin instead. For example, there’s no need to run ifconfig as root if you only want to display the current set of addresses. Yet it lives in sbin.

This means that in practice people will just add sbin to PATH to get a somewhat usable system, which makes the division between bin and sbin useless.

Furthermore, on BSD derived systems binaries that should not be invoked by users directly (e.g., daemons) need to be stored in libexec.

>>tremon+(OP)
Don't you need sbin in PATH anyway when you want to run them with sudo?

>>EdScho+Y4
/sbin is for statically linked executables, while /bin is for dynamically linked executables. It has nothing to do with daemons vs non-daemons, nor with things having to run as root.

>>pmoria+Mb
Go take a look (using ldd) in your /sbin and tell me exactly how many of them are statically linked. On my system, only 170 out of the 838 items in /sbin are statically linked.

>>pmoria+Mb
Then why is /sbin missing from PATH in Debian? Does that mean that only root can run statically linked binaries?

>>pmoria+Mb
I can recall any Linux distro or Unix variant setup in the way you describe. In addition, the Filesystem Hierarchy Standard disagrees with you.

https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

You may be thinking of the /bin and /usr/bin difference, though.

>>usrbin+G4
Been using Linux for years and it still trips me up when it tells me "command not found".

>>pmoria+Mb
https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

> Utilities used for system administration (and other root-only commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains binaries essential for booting, restoring, recovering, and/or repairing the system in addition to the binaries in /bin.

>>rascul+Uh
I believe they're referring to the old SunOS (at least) convention that /sbin was for utilities that could be run during the boot process before /usr was mounted. These tended to need to be statically linked, as the .so libraries were all under /usr. SunOS was how I learned the Unix filesystem layout, but of course that means a lot of my ideas of what "should" be where are outdated at this point.

>>Sakos+nk
I totally got thrown a curve ball when Debian started telling me 'shutdown' was not found...

>>techno+4q
> I believe they're referring to the old SunOS (at least) convention that /sbin was for utilities that could be run during the boot process before /usr was mounted

My memory is hazy but I recall the distinction being / vs /usr not /bin vs /sbin.

>>tremon+(OP)
I do on my laptop Dev environments, but I do understand your point, it’s not a use case any but resource constrained devs do.

>>mekste+Cb
There's a "secure path" option in sudoers that you can use to add additional directories to the path that is searched when sudo is invoked.

Most examples will include the standard user path plus /sbin and /usr/sbin but you can add any directories you want to the option.

>>smhend+4C
Isn't that for executing than autocompleting?

>>rascul+Qr
The article we're commenting on has that as the justification for /usr/bin and /bin in the second paragraph.

>>codedo+be
The tools that root needs are more often served by being statically linked than dynamically for the situations where the volume with the shared libraries fails to mount.

Having mnt be statically linked makes it much easier to recover that system.

The ideal of "/sbin for system tooling" isn't so much one of static vs dynamic but rather users accidentally finding system tools that don't work and sending email to the admin saying "mnt gives me a permission denied error" when they have no business running it.

>>techno+4q
Rather, the convention was that /sbin was for static binaries so that the system could still be fixed online if the dynamic linker got hosed. It's not about /usr not being mounted, but /lib/ld-linux.so not functioning correctly. For that reason, glibc still ships (or used to ship) an sln binary (static ln), and Debian still offers sash (stand-alone shell): so you could at least try to restore the dynamic library link farm by hand.

But I have only ever seen historic references to that argument, from back when dynamic linking was scary and unreliable. I certainly have never encountered that situation in almost 25 years of using Linux.

>>pmoria+Mb

    $ file /sbin/* | grep "dynamically linked" | wc -l
    325

    $ file /sbin/* | grep -i "static" | wc -l
    0

On Ubuntu focal, but Red Hat is similar.

>>pmoria+Mb
sbin as "static binary" is an ahistoric retcon, like claiming usr means 'universal system resources'. (It means 'user' and was the original /home.)

>>mekste+Cb
What if I want to run fsck on a drive image owned by my user? If I can run /sbin/fsck, I can rightly run that on such a file without using sudo.

>>monoca+aR
Pretty sure on both of those /sbin is just a symlink to /usr/sbin. If the static thing was ever true I suppose once you've moved everything in to /usr you wouldn't bother anymore.

>>mekste+KD
Yes, that's correct, it's only about searching the right directories to find and execute the program you asked for.

But autocomplete after sudo doesn't work for me on a stock Debian install anyway, not sure what one needs to do to get around that. I don't really rely on it. If I'm doing enough work that needs root I start the session with "sudo su -" anyway so not having autocomplete after sudo is not a big deal for me.

>>tremon+(OP)
> Having only usable binaries in the path aids discoverability of the system.

Downside is it stops the autocomplete, so if you, say, wish to check quickly how binary is called on the system, e.g. if you should sudo apache2 or httpd, it will not work...

>>tremon+(OP)
> the value in having a bin vs sbin split is in keeping system binaries (daemons, root-only tools) off the user's path

I think it's nice to be able to keep admin utils out of an admin's PATH when the admin isn't intending to use them.

It's much less interesting to me to keep daemons and such out of anyone's PATH if running them can't do much, though usually those things really belong in a libexec directory and should be exec'ed intentionally only.