Hacker News Reader

Comment by santiagobasulto | Hacker News Reader

Great story, I love these! Personally I always thought that the difference between `bin` and `sbin` was that `sbin` contained binaries with Superuser privileges (hence the `s` at the beginning).

View on HN

The s is for "statically linked". Binaries that run early enough in the boot process that /usr/lib might not be there yet.

Sources I find claim "system binaries":

http://www.linfo.org/sbin.html

Yes.

My system does it like this.

    /bin - static linked basic user commands
    /sbin - static linked system commands (incl. important daemons)
    /usr/bin - dynamic linked user commands
    /usr/sbin - dynamic linked system commands and system daemons
    /usr/local/bin - user commands installed via package
    /usr/local/sbin - system commands installed via package

I have been using Linux/Unix boxes for 19 years. I am ashamed to admit that I never learned this until now. Thanks!

Don't feel too ashamed. I also learned a lot from this article and I've been using Linux/Unix boxes for even longer than you.

Is it ? Root and admins have sbin in their path while normal users don’t, so sbin contains more system exe. they may happen to be also static because they are called early in the boot. At least that’s what I thought

For example, /sbin/sh was statically linked on the various flavors of Unix, while /bin/sh was dynamically linked.

So, I suppose it's really both. The statically linked shell would allow you to upgrade the shared libc, for example. Which is both "system" and "static" related.

This story isn’t about the difference between bin and sbin.

edit: Clearly I'm missing something in the linked article because I'm being downvoted. Could someone show me what I'm missing?

Well, it kind of is: "The /bin vs /usr/bin split (and all the others) ...".

It really isn't. The story explains why some directories in / have an analogous version under /usr. If reading this article informed you about the difference between bin and sbin then ... I'm really not sure what to tell you because the article doesn't contain anything about this.

One can learn a modicum about the differences among lbin, mbin, rbin, bin, 5bin, sbin, amdahl/bin, ucb, sun/bin, ccs/bin, local/bin, xpg4/bin, xpg6/bin, and some others at https://unix.stackexchange.com/a/448799/5132 .

The headline promises it, but the story doesn't tell.

I don't know what the correct historical explanation is. "s" like in super user, system program or statically linked or is there yet another theory?

The headline is unfortunately a little ambiguous. We could clarify it by introducing some extra punctuation and modifying it slightly to make it clear the "split" in question is between "/" and "/usr":

"Understanding the split between (/bin, /sbin, /lib) and (/usr/bin, /usr/sbin, /usr/lib)"

Not perfect but maybe clearer

I thought it meant "secure", as in the programme what you can use when your system crashes into a "secure" mode or something like that.

Wait, that's not the reason?

It kind of is and isn't.

So sbin is reserved for system binaries concerned with booting, administrative tools, repairing/restoring (the system), and the like.

Since these essential utilities by their very nature require superuser privileges, it's tempting to think that sbin simply means "superuser binaries" or something.

Someone else mentioned "statically linked", which is also true, but again just a side-effect of being for system programs. The programs in sbin need to be able to run without /usr, /lib, or /bin being mounted or even existing is the idea here.

To me personally - and this is just my uniformed(!) opinion - the only split that makes sense across all circumstances is /bin vs /sbin and /var vs /. Simply because anything but /var could safely be considered read-only, while /var exists explicitly for writable data ¯\_(ツ)_/¯

Also, you can mount /var with no executable set, for security purposes. If you go through the various security guidelines (such as STIG and various others), they give several paths that should exist as individual mount points -- both for the purpose of setting appropriate mount options, but also if a user program has write access somewhere in it, then they can't cause a disk-full condition on another (logging-type) path.

Same with /tmp - mounting it and allowing executables is a recipe for disaster in a multi-user web hosting environment.

Splitting data by access pattern is still valuable today: setting permissions, using different filesystems and so on

It doesn't help that many distros don't add sbin to the path of normal users.

Reply on news.ycombinator.com