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.
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.
Yocto or Buildroot are rather common for embedded Linux. They tend to be a bit easier for the mostly static embedded systems, where everything gets cross-compiled and distributed together. They also make it pretty simple to generate a manifest with all the licenses and attributions and source files needed for every package included in the build that's under an OSS license.
What world is that? The distinction has lacked meaning on linux for far longer than it has existed, as the subset in /bin /sbin and the /usr versions thereof don't form any useful subset of functionality.
In embedded, most of the time everything in a base image (/bin and /usr/bin stuff, not to mention /sbin) will be flashed to a single partition.
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.
Absolute FUD nonsense. Actual greybeards know that the Linux kernel doesn't care if your binary is in /bin or /sbin, as long as you set up PATH accordingly. It's literally all you need to do.
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.
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"
In the state of immutable distros that use a modern image format (so not Android), /usr is read only and managed by the system only anyway.
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.
fun fact: you can already have almost everything except /var/ and /home/ read-only (there are still some legacy problems in /etc/, namely passwd, shadow, group... that I think userdbd can handle, but are there because of backwards compat). You can add to /etc/ by using systemd-confexts and overlaying files onto there (and systemd-sysext for /usr/). ~~Tho you have to choose the software you run somewhat carefully~~ Lets rather say, the infrastructure is already mostly there for this to be possible.
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).
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.
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.
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.
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”.
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.
> 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.)
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.
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.
"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.
(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.
I agree that “/usr/sbin directory becomes a symlink to bin” can be confusing for new users, but I don’t think it’s wrong: I interpret this statement as saying that /usr/sbin is going to be a relative symlink with target bin, which would indeed make it resolve to /usr/bin.
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.
I was curious why they are making the change now so I skipped right to the "benefit to fedora" section. They do not mention mounting /usr RO anywhere. Was this brought up in previous discussions? I do not understand why merging bin and sbin allows for mounting /usr RO.
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?
I think GP was saying that it’s /usr/bin rather than /bin for mounting as readonly. Not that merging any particular sbin with bin serves the purpose of readonly mounting.
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!
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)
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.
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).
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.
> 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.)
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.
> 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.
It is even getting worse, valve, willingly on not, is using it's domination of this market to force into a specific configuration the elf/linux distros (you better have an "expected" output of the glibc /sbin/ldconfig, some libs and modules exactly at the right locations and with the right symlinks), and forces some significantly expensive technical components beyond video game core system interfaces (bash, user/mount linux kernel namespace, niche gnu-only options of commands,etc).
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.
Insulting the author of the change request, when it is you who failed to understand the request and how it maintains backwards compatibility is quite strange.
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.