Systemmd is exposing something much deeper and icky as a normal file system object. That is beyond wrong.

It is the linux kernel who does that. Systemd just mounts what the kernel exposes. You can't be all unixy and everything is a file, without file systems.

I think the blame is put on the wrong party here. Systemd mounts efifs so that only root can rw to it, root rm the fs, hardware is affected. Places where there is a bug, hardware+firmware + unix idea that everything must be a file. Systemd follows the specs and behaviors that are expected of it. If the EFI fs should not be a FS complain to Linus. If the EFI should not brick itself after a rm / complain to EFI developers.

Systemd already took the reasonable security precautions. Root can rm anything it wants on Unix systems. rm efi fs is dangerous, so only root can do it. If root does it then all bets are off. Root needs to be able to write to the fs, per api and other tools needs.

People are quick to blame Poetering, but it is Linus who is leading the project which has the design decisions that are causing problems.

In the end it sounds like 3 projects needs to change their code to avoid an issue with a user mistake/bad firmware combo that only avoids that issue an a blue moon Monday.

All in all the usual storm in a tea cup against systemd. In that case it is funny because the issue is that systemd is to unixy :) everything is a file (system).

Everything you say is true. It would still be better for systemd to mount that filesystem read-only, and for the few (root-only) utilities that need to write to it to remount it read-write, write to it, and remount read-only.

Another reasonable option would be for a distribution to include SELinux policies that allow only the blessed tools (grub-install, systemctl, etc) to write to that filesystem. It would be a big change, though, because most distributions leave root and normal user logins unconstrained.

Except you only say this in hindsight. When developers were adding the efi mounts the only sane and reasonable assumption was "the bios is providing us write access to a table in its internal memory, this must be configuration data unrelated to the actual boot process and only needed for communication of data between bios and os".

In hindsight you can say "we should have mounted efi ro and made our efi tools much more complex so they can remount it rw write to it and then remount it ro again" but that is asking the systemd and efitool developers to have been prophets that motherboard firmware makers would be so disastrously inept and stupid they would put essential parts of their boot process in a shared variable table with the OS.

Its like saying you cannot ever introduce a memory clear into a GPU shader because you might wipe the firmware and the GPU could explode when its fan shuts off. You have to have the reasonable expectation the API you are working with is conforming, and when it is not you need to raise hell about it, and in the short term introduce the work around until the upstream problem is resolved.

The issue here though is that the upstream problem is proprietary farmed out awful firmware that restricts your freedom and bricks your hardware because nobody can audit or fix its terrible design.

Oh, no, I'm not saying what they did wasn't reasonable at the time, nor am I saying that the blame doesn't lie with the firmware vendors. Just that now, we know how bad the problem is, and a few possible workarounds.

Not everyone who runs linux wants to learn what is necessary to spend hours doing whatever the opposite of "automatic" is.

I feel for those people, I do. But in this market, you can't get something which does the right thing, without hours doing the opposite of "automatic". Such an offering does not exist. You can live with a system that has various issues due to malware, or major updates breaking things you depended on, or get someone who did spend many many hours learning to spend a couple hours fixing your problems.

OS X isn't too bad of an approximation though, if you don't sign into iCloud, turn off spotlight integration with internet services (see the recent story about people's macs crashing due to a malformed response from the server!) and don't link your iPhone to a mac (or don't have one). Finally, don't update to the next release until just before it's replaced by another, e.g. don't upgrade from 10.10 to 10.11 until just before 10.12 is released (but do install security updates of course).

But then again ... you'd have to be a bit of an expert to know whether you could trust my advice, and if not, who to trust, especially since you'll definitely get contradicting advice from similarly-knowledgable-sounding people ... so you're ultimately on your own.

The road to compile your own kernel and build your own distribution is well documented and there is even several books on the topic. Compiling your own system from scratch without the aid of a distribution makes it easier to appreciate the automatic defaults that usually gets installed.

I personally do not want to be forced to know all the hazardously settings that exist in the kernel and base system. I want sane defaults, defaults that are set automatically when I install my Debian packages. If I disagree with an automatic default, my options are to either utilize the control (freedoms) that FOSS software provides, or issue a bug report and try get the community to agree with my views.

If "rm -rf /" is a valid use case/concern, send up a bug report. Its better than trying to remove automatic defaults from distributions.

> I personally do not want to know all the hazardously settings the kernel has, where even a single mistake could spell the ruin of the whole machine.

That's kind of an ironic argument to make, given that you are using it to argue in favour of a design where a single mistake can actually brick your machine to the point that fixing it needs a soldering iron.

And you think in this case allowing the user to brick the system is the sane default, instead of putting it hinter an (easy to flick) switch?

It is behind and easy to flick switch called: su or sudo. The claim is that systemd should add a second switch because the first one is "not enough" that the systemd devs disagree with.

There are more operations that root can do that can brick a system or destroy hardware. Why should systemd try even harder to make root not do that?

Because working with su/sudo is still something that's often enough required for normal operations, that IMHO shouldn't have side-effects of that level. The "with great power..." spiel sudo displays is nice, but it isn't just experienced sysadmins running sudo anymore.

Since the OS doesn't provide permission levels to express this difference, it makes sense to create that isolation otherwise.

I've run rm -rf as root in the wrong directory before, and nuked stuff that required a backup to fix. I'd prefer if everything worse than that required some extra mental confirmation that, yes, I'm sure I want to do that.

There is always SELinux which can limit root. It was fairly easy to setup last time I tested it, and there has been attempts in the past to put it in as default.

A lot of distros also alias "rm" to "rm -i", something that many users explicitly disable. Its a complex problem of security vs usability where most discussions has been rehashed several times.

Personally i find rm too accepting, and rm -i too restrictive.

Using rm on its own will happily perform the command without further verification.

On the other hand, rm -i will request a yes/no on every last file involved.

Personally i have taken to using mc for any "complex" file system manipulations.