> Well, there are tools that actually want to write it.
It needs to be accessible in some manner.
> The ability to hose a system is certainly reason enought to make sure it's well protected and only writable to root.
Agreement it needs to be guarded, because it's a problem if it can hose a system.
> But beyond that: root can do anything really.
This is a truism for Unix, and altering this is much more of a problem than the occasional bricked machine. This is free software, and the ability to use it to control our hardware to the fullest extent possible is part of that freedom. Root cannot and should not be restricted from doing what it needs. It can, have hurdles put in place to make it harder to accidentally do something it doesn't mean to do though.
So, agreement on the problem, and agreement that something needs to be done to fix it, and a caution that access can't be entirely closed off without consequences, so root needs access. What's so horrible about that?
My personal opinion is that, for the use case of a single-user machine (i.e., "Linux on the desktop"), the traditional UNIX root isn't a useful concept. What's actually sensitive is your files, your saved passwords, your browser cookies, your emails, etc.; the ability to reconfigure drivers or replace OS components is only a problem because it allows all of those things to be compromised. Instead of throwing roadblocks in the way of root (remount ro, expose it as something more complicated than a filesystem so innocent users aren't tempted to look at it, etc.), let's take all the stuff that users should be able to do and make it accessible by nonroot, and take all the stuff they shouldn't be able to do and put it in the realm of automation.
UEFI has a pretty reasonable concept here, of a distinction between "boot" and "runtime" configuration; the BSDs have a conceptually similar idea of the securelevel. The idea is that if you're around during the boot, you might be interested in reconfiguring what the machine is doing, but as soon as you're out, you permanently abjure any further ability to reconfigure that. If we take a variant on that, that the OS doesn't abjure those capabilities as a whole but instead reserves them for itself, disabling all user-controlled ability to change things, I think we get very far. You can install new software, but not change the trusted sources for software. You can apply firmware updates via an existing cronjob, but not make arbitrary changes to firmware variables. If you want to do any of that, you have to reboot and enter a special setup mode. Apart from protecting against simple human error, this also serves as a very effective protection against malware: non-OS software simply has no ability to do unwanted things.
Then let's use UNIX users (which are a pretty solid isolation technique) to isolate things like your banking info from your Flash-requiring music service.
Chrome OS, incidentally, has this concept of things the OS can do that the user has no interface to, and Chrome OS is basically the most successful Linux on the desktop, so.
There's a difference between a system which, at all times, is one mistyped command from being bricked, and a system which allows you to brick it if you're explicitly doing something dangerous in the first place.
> let's take all the stuff that users should be able to do and make it accessible by nonroot, and take all the stuff they shouldn't be able to do and put it in the realm of automation
While theoretically reasonable, this is also a huge project, and while this project is slowly implemented users are still vulnerable to this bug. Additionally, there's always going to be Linux users who find the idea abhorrent, and thus it remains a bug for those users. Choosing to have more control should not generally mean that you can brick your machine so easily as accidentally deleting a few files.
Precisely how many user space apps do you think need access to it?!?
A better example is that `/` is a special case for `rm`.
(Besides: I'm not a fan of `rm -i`, precisely because it's non-default. You'll get used to it, and then someday you accidentally some files on a system where you didn't add the alias.)
I don't remember anything about my time with SUSE and Ubuntu, thats way back.
* I normally use zsh with grmlzshrc and nearly no customization (which is why I love grmlzshrc -- usable defaults), which warns for `rm -rf foo/*` but not for `rm -rf foo`.
\rm -rf somedir
Yet by default, if you don't include the "\", you get rm -i
.bash_history says I accidentally added `-f` on that host. I should have just checked with `which` instead of trying it out. Oops.
type rm is better than which rm, but it depends on what distro you're using. Some distros (Just checked on RHEL7) will fancify which as well ie:
$ type which which is aliased to `alias | /usr/bin/which --tty-only --read-alias --show-dot --show-tilde'
Yes, I know, but rm ignores -i if -f is given.
[root@example ~]# touch blah
[root@example ~]# rm -i -f blah
[root@example ~]#
[root@example ~]# which rm
alias rm='rm -i'
/usr/bin/rm
[root@example ~]# touch blah
[root@example ~]# rm -f blah
[root@example ~]#
Nowadays I spend most of my time in Windows and mobile OSes to remember it properly.
Maybe one there is some nasty Windows Virus out there that fries boards by deleting EFI variables these stupid vendors will get their shit in order.
Perhaps systemd could shield users from their motherboard's manufacturer's stupidity, but the amount of flack being received doesn't seem warranted; has the same amount of outrage been directed towards the manufacturers?
If you look at how probing for hardware works in the Linux kernel, quite a few older drivers (and the occasional feature subtree) have auto-probing disabled by default because it tended to crash some types of hardware. You see this again in lm_sensors, where the auto-probe script specifically asks permission (with a default "no") before it tries certain probes that risk crashing the hardware.
We don't see this as much in recent years as hardware has gotten better - listing the device_ids/vendor_ids on a buss is much safer than poking ISA IO ports - but the problem remains. Some hardware needs special hand-holding, especially in the initial probe or initialize stages. Hence, tools that handle those stages are always going to have special cases and other annoyances.
> the amount of flack being received doesn't seem warranted
The flack against Pottering (and the rest of the systemd cabal) is because this isn't the first time his idealism has caused serious problems for others. Yes, it would be nice if we could just mount UEFI areas (or anything else). In reality, as this bug shows, this is dangerous behavior. It should have been made optional, or the entire idea of exposing those UEFI areas as a filesystem should have been reconsidered - a special purpose tool that handled bugged hardware might have been more appropriate.
Robust systems must work in the real world not just in an ideal one.
Some boards do have something of a "factory reset" in the form of dual bios so that if one is bricked, the backup can still be booted. But it's not a bug that not every motherboard has this feature.
The UNIX philosophy of "everything is a file" has always been based around the conceptual 'contents' of these 'files'. The kernel doesn't (directly) care if you remove a device node (block or character-based), it doesn't care if you remove a pipe, and it doesn't care if you remove a socket - even though all of these things are interfaces to the kernel in one form or another. Removing these files only removes your ability to access that interface.
Simiarly with files in /proc - which, like /sys, is directly exported by the kernel. In many cases the kernel refuses to even allow you to unlink the 'files' in /proc, even when it might make sense. (For example, you can't kill a process by 'rm'ing anything in the relevant /proc directory.) Instead, you update the configuration values that the files in /proc represent by echoing into their contents, where applicable.
The case with the efivars 'file' actually causing the kernel to take action when it's removed is what's at issue here. The fact that it happens to brick some computers is particularly unfortunate, but does a good job with showing the problem here. This isn't what the "everything is a file" philosophy is about.
I think SystemD is in the wrong here. Operating Systems should be protecting users from bricking their hardware.
Harware manufacturers should not be shipping hardware that's nearly impossible to brick, because it results in hardware that is nearly impossible to update.
Quite a few boards have a backup EEPROM to initialize from if the primary EEPROM fails to boot, but who knows if those that do will bother to reinitialize the UEFI variables stored in NVRAM. Honestly, since they are just supposed to be stored in NVRAM what happens if your board battery runs out of juice, will it still brick?
Hosing a system is something that can be fixed by root by reinstalling from scratch or restoring from backup. Bricking hardware is not something a sysadmin can fix by himself.
Poettering attitude refusing to acknowledge his mistakes and fixing them is not something new.
Someone who doesn't get the difference between deleting the content of a drive and rendering hardware inoperable shouldn't be in charge of a critical system component.
Maybe it's not his responsibility and distro creators need to protect it, I don't know.
-Slackware fortune file
I tend to think the Linux on the desktop thing is a bit of a diversion, but this issue and Poettering's response certainly lend weight to the concerns many have raised about systemd.
What happened to defence in depth? Even if your users are all perfectly competent, with this sort of arrangement you're one vulnerability away from having bricked boxes, not just one vulnerability away from reimaging and restoring from backups.
What happened to making systems safe by default? There is no need to make this kind of system so fragile.
What happened to using the right tool for each job? The obsession with making everything look like a file that lives under the same global file system hierarchy causes endless problems, and it's never been entirely clear to me what benefits it's supposed to offer in return. It's interesting that Poettering remarked on exposing /dev/sda as root as well, because it's another excellent example of how broken this model is.
What happened to minimising trust? Of course it's crazy that any hardware/firmware actually allows itself to be permanently broken by a software error like this, but the software should not assume the hardware/firmware will take responsibility for providing any necessary safeguards.
Ultimately, this is just bad engineering and bad UI. It can result, and reportedly has resulted, in serious damage. No amount of dressing it up will change that, and the root cause of the problem should be fixed.
Ultimately access is needed to even configure the bootloader, and right now that means it needs to be mounted RW. Let's go yell at the kernel developers instead of taking it out on systemd for using a virtual filesystem instead of a syscall.
There's no point in mounting efivarsfs read-only; you might as well not mount it at all.
Despite the fact that they're primarily a systemd distro, Arch Linux strongly recommends that you mount efivarfs in ro mode and remount rw when doing kernel upgrades.
GRUB2 seems to use efibootmgr to write stuff to EFI, and efibootmgr appears to lack a "detect if efivarfs is mounted ro and temporarily mount it rw" switch, so you have to do that manually too.
Gentoo's Genkernel-next doesn't seem to do anything at all with EFI.
Dracut (one of RedHat's initrd management tools) looks like it reads from efivarfs, but does not write to it. (But there's a lot of code in Dracut, so it's entirely possible I missed something.)
It's not entirely clear to me that you can't use BIOS boot with a GPT-formatted disk if your bootloader supports that sort of thing. It's also not clear to me whether or not chainloading from GRUB into Windows is supported with a BIOS/GPT partitioning scheme.
Regardless, it's a pity that the UEFI design committee apparently thought that requiring one to write data into the motherboard's persistent storage in order to boot into a OS was a reasonable thing to do.
Why not leave it unmounted entirely, and only mount it when installing new boot entries?
Because there are -presumably- reasons to read EFI variables? If they're exposed through efivarsfs, then it's a convenient way to access them.
You'd think that efibootmgr would have a "--temporarily-remount-efivarsfs-readwrite" flag to handle that very thing, given hardware vendors' long history of getting UEFI dangerously wrong. :/
And of course, sticking to proprietary solutions in a long run would be rather a sick idea.
That's what distros are for. The "Linux" family of operating systems are used for a very wide variety of uses, some of which are orthogonal (and sometimes incompatible) with "desktop" features.
Something like "Year of the KDE desktop" or "Year of the Linux Mint desktop" would make much more sense than trying to shove all of Linux into one pigeon hole. In fact, even within "desktop" there is variation. While an easy to use, mostly automagic desktop is a good idea, that's not the only definition of "desktop".
Ultimately, this is the the biggest problem with the idea of "THE Linux desktop"[1]: one size never fits all. Fortunately, Linux distributions exist[2] allowing for great variety - including "everything just works" desktop distributions. Just remember that the Linux ecosystem is larger than one type of distro.
[1] and systemd, and 15+ years ago the "desktop environments" that insisted there should be only one GUI toolkit, etc
[2] This assumes distros decide to keep their own identity instead of continuing on the homogeneity bandwagon that many joined when they converted to systemd. Turning into a clone of Red Hat is the path to obsolescence.
When that happens, I don't think the Canonical or Redhat will be able to compete, and only Google will be able to create an OS on top of Linux, and open-sourcing won't do any good because the most important services will be behind Google servers.
That the dominate platforms have any customers at all just illustrates how mediocre the entire software industry is.
If software were medicine we would still be leeching people and learning about the miasma theory of germs.
The desktop / personal user domain is looking like it's in the early stages of transformation, with mass data collection to support voice search and user intent prediction. While there's something to be said for privacy, I don't think consumers will care enough, and I don't think desktop linux systems outside of whatever Google may make is going to be adequately competitive.
This will likely not be a server concern. Engineers probably won't be interested in a service that opaquely collects data and sends it off to remote locations just so that they can say, "Cortana, run the Ansible script to redeploy my API server." But desktop users would find value in saying, "Cortana, move all email from unknown entities to my todo list."
And if my assertion that intention prediction and voice search will be competitive features for users, features that rely on mass data collection and expensive top talent, then I think organizations like Canonical or RedHat will fall behind in the desktop/mobile/user os space.
Apple's no M$, but they are certainly competitive.
When I think of what organizations will be competing on machine-learning backed features like intention prediction or voice search, I think of Apple, Microsoft, or Google. Those OS features won't be inside the OS. They'll be backed by a wealth of proprietary data hidden behind company servers.
I think user expectations for what a modern OS ought do will evolve, and I don't think Canonical or Redhat will be able to catch up to Microsoft, Apple, or Google.
Eventually, what we think of "Linux OS" will be Android (and if you want, OS X) and maybe some other offerings by these big giants, but the most user-demanded features won't be on the OS. Therefore, Samsung can't just fork Android and expect to compete sans Google, and Canonical or Redhat won't be able to compete either.
Apple can't take code from Linux as the code is GPL licensed. OSX is largely based on NeXT and BSD. Linux and OSX are both POSIXish though.
Offices most certainly could run linux only if they weren't chickenshit (I mostly kid, but after seeing how broken the desktop management model is now anyway, I don't see why Linux can't be used more in Corporate.)
Either way is going to break things and I'm sure there'd be people lining up to complain about them making it ro by default or adding some sort of safety layer in. Might as well leave it as it is and let the various distros do what they want with it. I do think though that someone should do something and this sort of thing shouldn't be possible, but I can understand the stance of leaving it up to the distros to decide as a reasonable compromise.
Last week after a storm I watched two blokes cut up some fallen wood. One held the chainsaw, the other ran the wood over the blade.
When you start using tools at a low enough level, there are some things you cannot guard against.
Mounting efivarfs read/write by default
can lead to accidental deletion of the
EFI variables. -- laloch
Anyone can "rm -rf" anything, that doesn't mean that they should.
I know, I was one of those before my bank got newer, smarter ATMs.
Actually, it's more like this. I remember when I used to blame my users for what my software could do.
Nobody sells a chainsaw with safeties disabled, remarking "you can always attach the chain catcher" if people report a couple of accidents, but Lennart thinks requiring almost every user to change the default install ((note that you can remount it readonly at boot, simply by adding an entry for it into /etc/fstab, that is marked "ro") is a better idea than mounting it read-only, and requiring those few who need to write these variables to do some extra work by remounting it read-write.