Fedora 41 will unify bin and sbin
fedoraproject.org
fedoraproject.org
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.
Pottering might do it, but... I dunno, does that affect embedded?
And a new generation of OSes that show some traces of UNIX influences will carry on.
Just like Windows still carries CP/M and MS-DOS traces on it.
I do not see what you are complaining about where no one is stopping you from installing binaries anywhere and on any mount you want.
When did greybeards expect to run user-friendly desktop distros on embedded devices, afraid of touching PATH? You are free to use anything else, or go LFS for ultimate customization, which is actually what I expect serious embedded devs to do.
Secondly, Linux has something called overlayfs which you can use to build a sandwich any way you want. That is to say, the contents of your /usr/bin directory (and others) can simultaneously come from multiple partitions, some of which are writable, without the use of any symlinks. Overlayfs will merge things.
With overlayfs, you can create an image that appears mutable, but is assembled out of read-only partitions.
The whole reinterpreting of "static bin" to "system bin" never made sense to me.
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.
> "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/074...
imho we should go the entire way and move /home to /var/home, so anything other than /etc and /var can be read-only, I already place /var on a separate partition with /var/home on RHEL installs.
I'd love to have a way to have root really only be a read-only tmpfs that is only used for mount points (specifically /usr/, /var/ and /home/) and symlinks (for example /var/home/ to /home/ if no separate partition is wanted).
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.
At least the old /bin vs /usr split served a purpose, even if that purpose is rather obsolete.
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”.
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.
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.)
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.
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.
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
/sbin -> /usr/bin
/usr/bin
/usr/sbin -> /usr/bin
/usr/local/bin
/usr/local/sbin -> /usr/local/bin
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.
- /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
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...
That feels so wrong to me.
The idea is that /usr can be a snapshot of your whole system. (/etc violates this but there’s ongoing work on that side)
The two issues seem totally unrelated to me. /usr/bin and /usr/sbin are directories under /usr. Why does making sbin a symlink allow for mounting /usr RO?
You could separate it I guess correctly between system-only bins again, but you'd break existing software that's hardcoded sbin and bin.
What does the fact that "there's zero difference between sbin and bin" have to do with mounting /usr read only?
Disclaimer: I’m mostly just a Mac user/interested spectator. It’s possible I’m misunderstanding GP, and it’s not clear to me why the /usr distinction matters for readonly mounting either. But I couldn’t help jumping in to see if I could help clarify something, because there are just an astonishing number of ambiguities and confusions about those ambiguities throughout the comments on this post!
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.
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.)
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.
Yes, this is mostly bad (msft grade), they should fix all of this. The guys who did that clearly where not the right ones, evil or with an accute lack of perspective and/or experience. First they have to follow ELF specs and certainly not expected "only some ELF specs in some specific way". They should provide clean (10 years old version names, libdl-ing system interfaces, static libgcc, static libstdc++, leave as much as possible of ELF static TLS slots to the system) ELF binaries and depends only on video game core system interfaces: Expecting bash from the user system, certainly not, they could expect a simple SH interpreter and no more (debian dash, busybox ash, etc). They could distribute their statically linked bash interpreter, as they are already distribute a gigantic part of a full elf/linux distro now (their "runtimes"). And this legacy opengl 32bits code... come on, they removed it from macOS, why elf/linux user have to suffer from it (that's actually fishy).
Hope valve leaves msft grade mediocrity behind at some point, because for the moment it looks like 1 step forward and 10 steps backward.
Oh and video game core system interfaces are: - wayland (code is static in binaries), fallback to x11 (libdl-ing x11 xcb libs). - libxkbcommon-x11 if x11, libxkbcommon if wayland surfaces are using xkb. - vulkan (libdl-ed by design), fallback to opengl (libdl-ed) fallback to CPU rendering. - libasound (alsa-lib) for sound. - linux /dev/input/eventXX device nodes for joypad support.
More than that is too excessive and not reasonable.
I agree most of the compatibility concerns mentioned are moot, but I guess it will cause small amounts of one minor ~forward-compatibility problem: people working on Fedora hardcode new paths that won't work on other distros unless/until they follow suit.
---
In late 2019 I started work on a tool for ~wrangling external shell script dependencies to help us package shell better in the nix ecosystem. (the tool itself is generic, but it's currently only packaged for nix.)
The main goal is to identify external dependencies in a ~source script, require them to be specified/present, and output a rewritten script with absolute paths.
It handles existing hardcoded paths by treating them as an error that the user has to address by either telling it to just resolve them as if they were bare, or to keep as-is.