5 ms·

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.