6 ms·

Fedora 41 will unify bin and sbin

80 points by rwmj 3y ago

rurban 3y ago
That feels entirely wrong to me. sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper cleanup.
- yjftsjthsd-h 3y ago
  OpenSUSE did that; it was IMO marginally inconvenient because (IIRC) it broke tab completion of sbin binaries, even with sudo. Ex, "sudo pow<tab>" wouldn't give you poweroff.
  - rurban 3y ago
    Well, that would be trivial to fix by detecting the magic sudo, and add /usr/sbin to the completion searchpath
- amluto 3y ago
  There are really quite few programs that can’t be invoked by regular-ish users in the brave new world of user namespaces. It’s also entirely unclear to me why trying to sort programs into these particular buckets is useful. At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.
  - spookie 3y ago
    We should learn from the xz incident. It's little things like these that make compromise harder. Not saying the fact that sbin exists did anything, but that more layers of armor is always better.
    - amluto 3y ago
      We should learn from the xz incident by adding real security. For example, the ways programs use libraries could be restructured to prevent libraries, and especially libraries whose functions are not called, from having side effects. Or packaging tools could learn to verify that a release is exactly a git commit and not some tarball that may or may not have any particular relationship to a commit. Or we could make sure sshd is in /usr/sbin? I don’t get it. What does that accomplish? It’s not as if the stuff in a directory called “sbin” is inherently more “secure”.
      - spookie 3y ago
        If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). Look, I don't say this as the end all, be all. Just another piece of the puzzle. Think of how chaotic Linux land is. It's true it can be thought as a liability, but distros' heterogeneous nature could also be a defense, and sbin itself can be thought as another defense. For example, in openSUSE Leap 15.6 at least, a lot of critical binaries are located in sbin. They are placed there not only as a static fallback for maintenance, but also as a means to minimize the attack surface of the OS. It is much more likely for your system to be compromised at a user level, and not at a superuser level. I know the xz incident wasn't the best example, and of course there are better solutions than this.
        amluto 3y ago
        > If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have. (Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)
    - Nullabillity 3y ago
      sbin is not, and was never, a security barrier.
- kazinator 3y ago
  Aren't you advocating breaking scripts that reference executables in /sbin or /usr/sbin? sbins that could be invoked by users cannot just move to /bin, if scripts expect them to be in /sbin. It looks like Fedora has decided that the sbin distinction is historic fluff. There is no need to put a program in a separate directory just because it makes system calls that require root and therefore fail for a regular user. The article makes it clear that before this change, there is already no /bin directory, but rather /bin is a symlink to /usr/bin and /sbin is a symlink to /usr/sbin. I.e. they already decided that the the shortened /bin and /sbin paths are historic fluff; everything will be in /usr. The symlinks are needed for compatibility. You know, like #!/bin/sh and whatnot. Now they are getting rid of /usr/sbin. So that becomes a symlink to bin (I'm assuming relative, I.e. /usr/sbin -> bin). Thus, all combinations of {/usr}?/{bin|sbin}/<program> become equivalent, and only /usr/bin is a real directory where all the system binaries live.
zoobab 3y ago
Finally, we only need /bin!
- kstrauser 3y ago
  Except on Fedora where it’s /usr/bin. That feels so wrong to me.
  - xena 3y ago
    The reason they are doing this is so that you can mount /usr as read-only or possibly on immutable storage.
    - Zambyte 3y ago
      Why can't you do that with /bin?
      - akdev1l 3y ago
        Because /bin only contains binaries whereas /usr is self-contained. It will contain icons/libraries/shared resources/etc that the binaries actually need to function. The idea is that /usr can be a snapshot of your whole system. (/etc violates this but there’s ongoing work on that side)
        Zambyte 3y ago
        I don't see the benefit of shoving every directory in / under /usr. / can already be a "snapshot of your whole system". Just mount /home separately if you don't want it included in that.
      - coldtea 3y ago
        Because it wouldn't contain the rest of the /usr
        Zambyte 3y ago
synergy20 3y ago
"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to usr/bin and usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH. The same change is also done to make /usr/local/sbin point to bin, effectively making /usr/local/bin/foo and /usr/local/sbin/foo point to the same place. The definition of %_sbindir will be changed to %_bindir, so packages will start using the new directory after a rebuild without any further action. Maintainers may stop using %_sbindir, but don't need to." the summary is very unclear for new users, was it saying _everything_ is now symlinking to /usr/bin? and /usr/bin is the only real directory the rest is all symlinks? The way of saying "symlink to bin" is just plain wrong or at least ambiguous.
- comex 3y ago
  I read that as saying that /usr/local/sbin will point to /usr/local/bin which will still be separate from /usr/bin. But /bin, /sbin, and /usr/sbin would all point to /usr/bin.
- chrsig 3y ago
  it's saying that anywhere that there was an sbin, it now is a symlink to it's sibling bin it's also saying that because /bin and /sbin point to their /usr counterparts, /bin and /sbin will point to /usr/bin So currently: /bin -> /usr/bin /sbin -> /usr/sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin we'll have: /bin -> /usr/bin /sbin -> /usr/bin /usr/bin /usr/sbin -> /usr/bin /usr/local/bin /usr/local/sbin -> /usr/local/bin (all assuming that I'm parsing the description correctly) which all makes sense, we'll have /usr/bin and /usr/local/bin, where the latter is for user-installed executables and the former for system installed executables.
  - kuschku 3y ago
    Previously, these folders existed: - /usr/bin, aka /bin - /usr/sbin, aka /sbin - /usr/local/bin - /usr/local/sbin Now, these folders exist: - /usr/bin, aka /usr/sbin, aka /bin, aka /sbin - /usr/local/bin, aka /usr/local/sbin
arp242 3y ago
I thought all the distros already did this with the /bin and /usr/bin merge; it's like that on at least Void and Arch Linux anyway. The whole reinterpreting of "static bin" to "system bin" never made sense to me.
- mrweasel 3y ago
  Debian is merging /bin and /usr/bin as well. The "static bin" makes sense, if you follow it very strictly, in that case it ensures that regardless of how much you damage libraries, everything in /bin (and /sbin) will still work. If you merge /bin and /usr/bin it becomes unclear which binaries you can rely on in an emergency. There's simply no easy way to tell at a glance. Merging bin and sbin makes a little more sense to me. It avoids the very common scenarios where you type "sudo mount" or "sudo ip addr", something like that, and our shell just return "command not found", simply because it's not in the users $PATH. It's a minor convenience factor, but I can't see it making anything worse.
  - spookie 3y ago
    Completely agree.
  - andrewshadura 3y ago
    In the event of an emergency, you rely on initramfs.
- jodrellblank 3y ago
  What about the reinterpreting of "usr" from "user" to "unix system resources" after Unix overflowed the original 1.5 MB OS drive on Thompson and Richie's PDP-7? > "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented" - http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
  - 3y ago
sylware 3y ago
Steam horrible bash (and not even sh) scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). The guys who wrote those are.. "geniuses"... I moved my stuff to /bin a long time ago, but I had to cherry pick stuff in /sbin to please steam stuff. Like you better have nothing in LD_LIBRARY_PATH and everything available via a stable output of /sbin/ldconfig (an abomination). All that to work around the abuse of gnu version names by the glibc devs (and gcc) via a super expensive user/mount namespace kernel mechanism. All that is msft grade, namely mostly bad.
- prmoustache 3y ago
  Since they will keep a symlink, there is no reason to expect any breakage.
- JadeNB 3y ago
  > Steam horrible bash scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). sbin is still there, just symlinked to bin. (But, yes, hardcoded paths are deeply irritating. Also install scripts that pass a path variable unescaped to another command, meaning that you can't have spaces in your paths.)
  - prmoustache 3y ago
    Well you definitely want to use hardcode paths in some scripts. For example those that call sudo.
    - JadeNB 3y ago
      > Well you definitely want to use hardcode paths in some scripts. For example those that call sudo. I can agree that there are cases for hardcoded paths to executables, but I'd argue that (aside possibly from working around the bad behavior of other tools) there's almost never a need for hardcoded paths to install folders, and that there's absolutely never a reason to use un-escaped variables in a path name.
egberts1 3y ago
Aside from the sbin/bin merger, Gone are the sane embedded world where we kept /bin in unchangeable EEPROM, /usr/bin in site-wide admin-controlled, and /usr/local where local admin roams and developers are left to their own device within the confine of $HOME/bin. Too many developers wanting to mess with things is getting expoundingly worse; even worse, non-privileged developers still pushing to centralized things to a single point of failure. We gray-beards lament the future and it is us.
- prmoustache 3y ago
  your embedded system doesn't have to follow fedora, or any other major desktop distro.
  - egberts1 3y ago
    Correct, but will Linux? Pottering?
    - yjftsjthsd-h 3y ago
      Linux doesn't care; it covers Fedora and Gobo and Android and NixOS alike. Pottering might do it, but... I dunno, does that affect embedded?
      - SAI_Peregrinus 3y ago
        It only does if the embedded developer wants it to. You can include systemd tools in your embedded release, but you don't have to. Just like you don't have to include GNU tools in your embedded Linux release.
        egberts1 3y ago
        That's why I use Gentoo/Linux and portage.
        3y ago
stefantalpalaru 3y ago
[dead]
deleted 3y ago
[deleted]
iJohnDoe 3y ago
Mini rant. I don’t know why people need to mess with stuff like this. Like the change of ifcfg-files. [0] Also, forcing nmcli to control network interfaces. CentOS 7 is truly great. Sad day when it’s EOL. Sometime it seems like stuff is changed for the hell of it rather than for good reasons. [0] https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye-ifcfg-files-and-hello-keyfiles https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye...
7bit 3y ago
A welcome change. The Linux directory hierarchy is in desperate need of a cleanup of old use-cases.
phendrenad2 3y ago
Finally. The bin/sbin split was originally done as a hack for someone's weird setup, but it doesn't make sense for MOST Linux setups today (and if you respond with "I use this feature" then you're just falling for perception bias, for your elucidation).
- rwmj 3y ago
  Wasn't it a Solaris thing originally? That's where I first saw /usr/sbin.
haunter 3y ago
Does this also come to the atomic versions, Kinoite and Silverblue?

80 points by rwmj 3y ago

That feels entirely wrong to me. sbin's that can be invoked as user need to move to bin instead. And the user PATH may not include sbin. That would be a proper cleanup.

yjftsjthsd-h 3y ago
OpenSUSE did that; it was IMO marginally inconvenient because (IIRC) it broke tab completion of sbin binaries, even with sudo. Ex, "sudo pow<tab>" wouldn't give you poweroff.
- rurban 3y ago
  Well, that would be trivial to fix by detecting the magic sudo, and add /usr/sbin to the completion searchpath
amluto 3y ago
There are really quite few programs that can’t be invoked by regular-ish users in the brave new world of user namespaces. It’s also entirely unclear to me why trying to sort programs into these particular buckets is useful. At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.
- spookie 3y ago
  We should learn from the xz incident. It's little things like these that make compromise harder. Not saying the fact that sbin exists did anything, but that more layers of armor is always better.
  - amluto 3y ago
    We should learn from the xz incident by adding real security. For example, the ways programs use libraries could be restructured to prevent libraries, and especially libraries whose functions are not called, from having side effects. Or packaging tools could learn to verify that a release is exactly a git commit and not some tarball that may or may not have any particular relationship to a commit. Or we could make sure sshd is in /usr/sbin? I don’t get it. What does that accomplish? It’s not as if the stuff in a directory called “sbin” is inherently more “secure”.
    - spookie 3y ago
      If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). Look, I don't say this as the end all, be all. Just another piece of the puzzle. Think of how chaotic Linux land is. It's true it can be thought as a liability, but distros' heterogeneous nature could also be a defense, and sbin itself can be thought as another defense. For example, in openSUSE Leap 15.6 at least, a lot of critical binaries are located in sbin. They are placed there not only as a static fallback for maintenance, but also as a means to minimize the attack surface of the OS. It is much more likely for your system to be compromised at a user level, and not at a superuser level. I know the xz incident wasn't the best example, and of course there are better solutions than this.
      - amluto 3y ago
        > If your distro is configured to assume everything under sbin requires elevated privileges, then I wager that would minimise the attack surface (I'm assuming sbin is treated as superuser owned binaries, not just as static binaries). I read this sentence several times, and I don't know what you mean. Some of the files in /usr/sbin are setuid-root (which, frankly, makes no sense -- traditionally, /usr/sbin isn't in non-root users' PATHs), but most are just plain executable files. The mere presence of those files in a place where non-root users could execute them is not an attack surface at all. They're just a bunch of bytes until someone executes them, and even then, executing them conveys no privilege that the caller of execve() didn't already have. (Unless you're running something like SELinux, in which case it's the job of whoever wrote the policy to make sure that the labels are appropriate.)
  - Nullabillity 3y ago
    sbin is not, and was never, a security barrier.
kazinator 3y ago
Aren't you advocating breaking scripts that reference executables in /sbin or /usr/sbin? sbins that could be invoked by users cannot just move to /bin, if scripts expect them to be in /sbin. It looks like Fedora has decided that the sbin distinction is historic fluff. There is no need to put a program in a separate directory just because it makes system calls that require root and therefore fail for a regular user. The article makes it clear that before this change, there is already no /bin directory, but rather /bin is a symlink to /usr/bin and /sbin is a symlink to /usr/sbin. I.e. they already decided that the the shortened /bin and /sbin paths are historic fluff; everything will be in /usr. The symlinks are needed for compatibility. You know, like #!/bin/sh and whatnot. Now they are getting rid of /usr/sbin. So that becomes a symlink to bin (I'm assuming relative, I.e. /usr/sbin -> bin). Thus, all combinations of {/usr}?/{bin|sbin}/<program> become equivalent, and only /usr/bin is a real directory where all the system binaries live.

zoobab 3y ago

Finally, we only need /bin!

kstrauser 3y ago
Except on Fedora where it’s /usr/bin. That feels so wrong to me.
- xena 3y ago
  The reason they are doing this is so that you can mount /usr as read-only or possibly on immutable storage.
  - Zambyte 3y ago
    Why can't you do that with /bin?
    - akdev1l 3y ago
      Because /bin only contains binaries whereas /usr is self-contained. It will contain icons/libraries/shared resources/etc that the binaries actually need to function. The idea is that /usr can be a snapshot of your whole system. (/etc violates this but there’s ongoing work on that side)
      - Zambyte 3y ago
        I don't see the benefit of shoving every directory in / under /usr. / can already be a "snapshot of your whole system". Just mount /home separately if you don't want it included in that.
    - coldtea 3y ago
      Because it wouldn't contain the rest of the /usr
      - Zambyte 3y ago

synergy20 3y ago

"The /usr/sbin directory becomes a symlink to bin, which means paths like /usr/bin/foo and /usr/sbin/foo point to the same place. /bin and /sbin are already symlinks to usr/bin and usr/sbin, so effectively /bin/foo and /sbin/foo also point to the same place. /usr/sbin will be removed from the default $PATH. The same change is also done to make /usr/local/sbin point to bin, effectively making /usr/local/bin/foo and /usr/local/sbin/foo point to the same place. The definition of %_sbindir will be changed to %_bindir, so packages will start using the new directory after a rebuild without any further action. Maintainers may stop using %_sbindir, but don't need to." the summary is very unclear for new users, was it saying _everything_ is now symlinking to /usr/bin? and /usr/bin is the only real directory the rest is all symlinks? The way of saying "symlink to bin" is just plain wrong or at least ambiguous.

comex 3y ago
I read that as saying that /usr/local/sbin will point to /usr/local/bin which will still be separate from /usr/bin. But /bin, /sbin, and /usr/sbin would all point to /usr/bin.
chrsig 3y ago
it's saying that anywhere that there was an sbin, it now is a symlink to it's sibling bin it's also saying that because /bin and /sbin point to their /usr counterparts, /bin and /sbin will point to /usr/bin So currently: /bin -> /usr/bin /sbin -> /usr/sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin we'll have: /bin -> /usr/bin /sbin -> /usr/bin /usr/bin /usr/sbin -> /usr/bin /usr/local/bin /usr/local/sbin -> /usr/local/bin (all assuming that I'm parsing the description correctly) which all makes sense, we'll have /usr/bin and /usr/local/bin, where the latter is for user-installed executables and the former for system installed executables.
- kuschku 3y ago
  Previously, these folders existed: - /usr/bin, aka /bin - /usr/sbin, aka /sbin - /usr/local/bin - /usr/local/sbin Now, these folders exist: - /usr/bin, aka /usr/sbin, aka /bin, aka /sbin - /usr/local/bin, aka /usr/local/sbin

arp242 3y ago

I thought all the distros already did this with the /bin and /usr/bin merge; it's like that on at least Void and Arch Linux anyway. The whole reinterpreting of "static bin" to "system bin" never made sense to me.

mrweasel 3y ago
Debian is merging /bin and /usr/bin as well. The "static bin" makes sense, if you follow it very strictly, in that case it ensures that regardless of how much you damage libraries, everything in /bin (and /sbin) will still work. If you merge /bin and /usr/bin it becomes unclear which binaries you can rely on in an emergency. There's simply no easy way to tell at a glance. Merging bin and sbin makes a little more sense to me. It avoids the very common scenarios where you type "sudo mount" or "sudo ip addr", something like that, and our shell just return "command not found", simply because it's not in the users $PATH. It's a minor convenience factor, but I can't see it making anything worse.
- spookie 3y ago
  Completely agree.
- andrewshadura 3y ago
  In the event of an emergency, you rely on initramfs.
jodrellblank 3y ago
What about the reinterpreting of "usr" from "user" to "unix system resources" after Unix overflowed the original 1.5 MB OS drive on Thompson and Richie's PDP-7? > "The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented" - http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
- 3y ago

sylware 3y ago

Steam horrible bash (and not even sh) scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). The guys who wrote those are.. "geniuses"... I moved my stuff to /bin a long time ago, but I had to cherry pick stuff in /sbin to please steam stuff. Like you better have nothing in LD_LIBRARY_PATH and everything available via a stable output of /sbin/ldconfig (an abomination). All that to work around the abuse of gnu version names by the glibc devs (and gcc) via a super expensive user/mount namespace kernel mechanism. All that is msft grade, namely mostly bad.

prmoustache 3y ago
Since they will keep a symlink, there is no reason to expect any breakage.
JadeNB 3y ago
> Steam horrible bash scripts have tons of things hardcoded to sbin... expect the worst (but the cherry on top is the usage of command gnu niche-options). sbin is still there, just symlinked to bin. (But, yes, hardcoded paths are deeply irritating. Also install scripts that pass a path variable unescaped to another command, meaning that you can't have spaces in your paths.)
- prmoustache 3y ago
  Well you definitely want to use hardcode paths in some scripts. For example those that call sudo.
  - JadeNB 3y ago
    > Well you definitely want to use hardcode paths in some scripts. For example those that call sudo. I can agree that there are cases for hardcoded paths to executables, but I'd argue that (aside possibly from working around the bad behavior of other tools) there's almost never a need for hardcoded paths to install folders, and that there's absolutely never a reason to use un-escaped variables in a path name.

egberts1 3y ago

Aside from the sbin/bin merger, Gone are the sane embedded world where we kept /bin in unchangeable EEPROM, /usr/bin in site-wide admin-controlled, and /usr/local where local admin roams and developers are left to their own device within the confine of $HOME/bin. Too many developers wanting to mess with things is getting expoundingly worse; even worse, non-privileged developers still pushing to centralized things to a single point of failure. We gray-beards lament the future and it is us.

prmoustache 3y ago
your embedded system doesn't have to follow fedora, or any other major desktop distro.
- egberts1 3y ago
  Correct, but will Linux? Pottering?
  - yjftsjthsd-h 3y ago
    Linux doesn't care; it covers Fedora and Gobo and Android and NixOS alike. Pottering might do it, but... I dunno, does that affect embedded?
    - SAI_Peregrinus 3y ago
      It only does if the embedded developer wants it to. You can include systemd tools in your embedded release, but you don't have to. Just like you don't have to include GNU tools in your embedded Linux release.
      - egberts1 3y ago
        That's why I use Gentoo/Linux and portage.
        3y ago

stefantalpalaru 3y ago

[dead]

deleted 3y ago

[deleted]

iJohnDoe 3y ago

Mini rant. I don’t know why people need to mess with stuff like this. Like the change of ifcfg-files. [0] Also, forcing nmcli to control network interfaces. CentOS 7 is truly great. Sad day when it’s EOL. Sometime it seems like stuff is changed for the hell of it rather than for good reasons. [0] https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye-ifcfg-files-and-hello-keyfiles https://www.redhat.com/en/blog/rhel-9-networking-say-goodbye...

7bit 3y ago

A welcome change. The Linux directory hierarchy is in desperate need of a cleanup of old use-cases.

phendrenad2 3y ago

Finally. The bin/sbin split was originally done as a hack for someone's weird setup, but it doesn't make sense for MOST Linux setups today (and if you respond with "I use this feature" then you're just falling for perception bias, for your elucidation).

rwmj 3y ago
Wasn't it a Solaris thing originally? That's where I first saw /usr/sbin.

haunter 3y ago

Does this also come to the atomic versions, Kinoite and Silverblue?