4 ms·

Great story, I love these! Personally I always thought that the difference between `bin` and `sbin` was that `sbin` contained binaries with Superuser privileges

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

QuesnayJr 7y ago
Wait, that's not the reason?
- qayxc 7y ago
  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 ¯\_(ツ)_/¯
  - derekp7 7y ago
    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.
    - kyuudou 7y ago
      Same with /tmp - mounting it and allowing executables is a recipe for disaster in a multi-user web hosting environment.
  - eeZah7Ux 7y ago
    Splitting data by access pattern is still valuable today: setting permissions, using different filesystems and so on
  - marcosdumay 7y ago
    It doesn't help that many distros don't add sbin to the path of normal users.
smcl 7y ago
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?
- mehrdadn 7y ago
  Well, it kind of is: "The /bin vs /usr/bin split (and all the others) ...".
  - smcl 7y ago
    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.
    - JdeBP 7y ago
      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 https://unix.stackexchange.com/a/448799/5132 .
- usr1106 7y ago
  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?
  - smcl 7y ago
    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
tyingq 7y ago
The s is for "statically linked". Binaries that run early enough in the boot process that /usr/lib might not be there yet.
- dredmorbius 7y ago
  Sources I find claim "system binaries": http://www.linfo.org/sbin.html http://www.linfo.org/sbin.html
  - ben_bai 7y ago
    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
- saber6 7y ago
  I have been using Linux/Unix boxes for 19 years. I am ashamed to admit that I never learned this until now. Thanks!
  - siberianbear 7y ago
    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.
- zaphirplane 7y ago
  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
  - tyingq 7y ago
    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.
0xdeadb00f 7y ago
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.

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

QuesnayJr 7y ago

Wait, that's not the reason?

qayxc 7y ago
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 ¯\_(ツ)_/¯
- derekp7 7y ago
  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.
  - kyuudou 7y ago
    Same with /tmp - mounting it and allowing executables is a recipe for disaster in a multi-user web hosting environment.
- eeZah7Ux 7y ago
  Splitting data by access pattern is still valuable today: setting permissions, using different filesystems and so on
- marcosdumay 7y ago
  It doesn't help that many distros don't add sbin to the path of normal users.

smcl 7y ago

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?

mehrdadn 7y ago
Well, it kind of is: "The /bin vs /usr/bin split (and all the others) ...".
- smcl 7y ago
  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.
  - JdeBP 7y ago
    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 https://unix.stackexchange.com/a/448799/5132 .
usr1106 7y ago
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?
- smcl 7y ago
  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

tyingq 7y ago

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

dredmorbius 7y ago
Sources I find claim "system binaries": http://www.linfo.org/sbin.html http://www.linfo.org/sbin.html
- ben_bai 7y ago
  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
saber6 7y ago
I have been using Linux/Unix boxes for 19 years. I am ashamed to admit that I never learned this until now. Thanks!
- siberianbear 7y ago
  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.
zaphirplane 7y ago
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
- tyingq 7y ago
  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.

0xdeadb00f 7y ago

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.