5 ms·

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 sta

by tremon 5y ago

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.

mekster 5y ago
Don't you need sbin in PATH anyway when you want to run them with sudo?
- smhenderson 5y ago
  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.
  - mekster 5y ago
    Isn't that for executing than autocompleting?
    - smhenderson 5y ago
      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.
- robonerd 5y ago
  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.
cassandratt 5y ago
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.
ivanhoe 5y ago
> 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...
cryptonector 5y ago
> 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.
gjs278 5y ago
usrbinbash 5y ago
> 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!"
- Sakos 5y ago
  Been using Linux for years and it still trips me up when it tells me "command not found".
  - Jaruzel 5y ago
    I totally got thrown a curve ball when Debian started telling me 'shutdown' was not found...
EdSchouten 5y ago
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.
- pmoriarty 5y ago
  /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.
  - rascul 5y ago
    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 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html You may be thinking of the /bin and /usr/bin difference, though.
    - technothrasher 5y ago
      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.
      - rascul 5y ago
        > 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.

by tremon 5y ago

mekster 5y ago

Don't you need sbin in PATH anyway when you want to run them with sudo?

smhenderson 5y ago
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.
- mekster 5y ago
  Isn't that for executing than autocompleting?
  - smhenderson 5y ago
    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.
robonerd 5y ago
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.

cassandratt 5y ago

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.

ivanhoe 5y ago

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

cryptonector 5y ago

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

gjs278 5y ago

usrbinbash 5y ago

> 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!"

Sakos 5y ago
Been using Linux for years and it still trips me up when it tells me "command not found".
- Jaruzel 5y ago
  I totally got thrown a curve ball when Debian started telling me 'shutdown' was not found...

EdSchouten 5y ago

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.

pmoriarty 5y ago
/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.
- rascul 5y ago
  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 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html You may be thinking of the /bin and /usr/bin difference, though.
  - technothrasher 5y ago
    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.
    - rascul 5y ago
      > 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.