SoylentNews is people
SoylentNews
A number of users have reported that running "rm --no-preserve-root -rf /" not only deletes all their files (as expected), but also permanently bricks their computers (which is not). Tracing the issue revealed that the ultimate cause was that SystemD mounted the EFI pseudo-fs as read-write even when this FS was not listed in fstab, and deleting certain files in this pseudo-fs causes certain buggy, but very common, firmware not to POST anymore. A user reported this bug on SystemD's GitHub issue tracker, asking that the FS be mounted read-only instead of read-write, and said bug was immediately closed as invalid. The comment thread for the bug was locked shortly after. Discuss.
Links:
https://github.com/systemd/systemd/issues/2402
http://thenextweb.com/insider/2016/02/01/running-a-single-delete-command-can-permanently-brick-laptops-from-inside-linux/
(Score: 5, Informative) by KilroySmith on Tuesday February 09 2016, @04:36AM
OK, so this was so confusing to me that I actually spent 15 minutes reading about it.
Linux allows mounting the EFI pseudo-FS. Everybody agrees this is a good thing.
SystemD always mounts it, and mounts it RW by default, because:
When you do your "rm --no-preserve-root -rf /", the EFI filesystem starts erasing stuff - as you've requested. If, however, you're new to a SystemD-equipped system, and aren't used to the EFI FS being mounted, you will unexpectedly start screwing with the EFI FS.
A tempest in a teapot. The only problem I see here is that the choice of default mount for the EFI FS - if they had chosen ro, there'd be no issue, and "systemctl reboot --firmware" could remount the FS RW for the length of time necessary to set the variable prior to rebooting. The choice of rw is dangerous even in the case where the EFI BIOS doesn't misbehave, because unexpected write access to the BIOS variables shouldn't occur.
(Score: 2) by jimshatt on Tuesday February 09 2016, @08:49AM
(Score: 2) by HiThere on Wednesday February 10 2016, @04:39AM
I think that leaving it mounted rw when you don't need it so counts as a bug. But certainly refusing to fix the problem when it starts bricking systems counts as a bug. And an extremely bad one, though the severity of the bug is not so much in the bug itself as in the administrative process holding it in place.
Prior to this event I had thought that the problems being reported about systemd were all "teething problems" and that they would go away as the software matured. Now It looks more like they are being intentionally frozen in place, though one may speculate about the reasons for why this is being done.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 5, Insightful) by pTamok on Tuesday February 09 2016, @11:14AM
There is a principle in security, which is the 'principle of least access' - you get the minimum access needed to do your job.
In this case, systemd opening the efi filesystem as rw when it didn't need to violates that principle: it should, as you point out later in your post, only open the filesystem for rw when it _needs_ to write, given what this pseudo filesystem is actually for.
If you think this argument is wrong, reflect on why some people prefer to use strongly typed languages. In principle, you can write everything in self-modifying assembler, and treat pointers as integers and have all sorts of fun - the point is not whether you can do it, the point is whether or not you should.
Having sane defaults is a good thing.
(Score: 5, Insightful) by Thexalon on Tuesday February 09 2016, @03:08PM
You know, this is the kind of response that truly bothers me. Here we have:
- A known problem with a pretty clear description of what's wrong.
- An obvious solution, namely to mount read-write only when you actually need to, because it's dangerously stupid to have it read-write all the time (as demonstrated by the problem)
And the response from Lennart Poettering is "won't fix, because it might require a bit of extra code for a single obscure feature". That's not the response to a bug that gives me any kind of confidence that Lennart should be in charge of anything remotely resembling a critical component of most major Linux distributions.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Friday February 19 2016, @02:55AM
You should have seen him defending breaking su because Pulseaudio somehow didn't work alongside it otherwise.
This by using systemd's pam module to alter a xdg environment variable if your ran su or su -l, so that anything that dependend on that variable to tell them where to stash their settings file would stop the initial users settings file.
His defense was that su was a broken concept.
Then later someone offered him a fix to pulseaudio so that the variable change was no longer needed. But this happened outside the bug report discussion, and the people following it had to rely on third parties to keep an eye on the various mailing lists. Eventually i think the bug report died because it was tired to a Fedora version that was no longer supported.
Then they introduce functionality to systemd that mimics su using Linux namespaces/containers.
Seriously, the whole systemd thing is a mishmash of OSX-isms, Solaris idolation, and an attempt to bypass Torvalds on kernel details by countermanding them via the init process (disabling sysreq combos, changing mount defaults, and the list keeps growing).