News for hackers. Stuff that matters.
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by EdSchouten on Wednesday May 11, 2022 @06:22AM (#31337927)
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.

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by pmoriarty on Wednesday May 11, 2022 @07:27AM (#31338349)
/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.
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by dmd on Wednesday May 11, 2022 @07:47AM (#31338493)
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.
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by nerdponx on Wednesday May 11, 2022 @08:28AM (#31338925)
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.

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by rascul on Wednesday May 11, 2022 @08:09AM (#31338729)
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.

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by technothrasher on Wednesday May 11, 2022 @08:54AM (#31339235)
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.
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by tremon on Wednesday May 11, 2022 @10:54AM (#31340851)
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.

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by rascul on Wednesday May 11, 2022 @09:03AM (#31339345)
> 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.

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by InitialLastName on Wednesday May 11, 2022 @10:09AM (#31340167)
The article we're commenting on has that as the justification for /usr/bin and /bin in the second paragraph.
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by robonerd on Wednesday May 11, 2022 @12:03PM (#31341880)
sbin as "static binary" is an ahistoric retcon, like claiming usr means 'universal system resources'. (It means 'user' and was the original /home.)
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by codedokode on Wednesday May 11, 2022 @07:48AM (#31338498)
Then why is /sbin missing from PATH in Debian? Does that mean that only root can run statically linked binaries?
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by shagie on Wednesday May 11, 2022 @10:51AM (#31340793)
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.

Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by monocasa on Wednesday May 11, 2022 @10:58AM (#31340915)

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

    $ file /sbin/* | grep -i "static" | wc -l
    0
On Ubuntu focal, but Red Hat is similar.
Re:Understanding the bin, sbin, usr/bin, usr/sbin split (2010) by amaranth on Wednesday May 11, 2022 @01:02PM (#31342745)
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.