Slashdot Mirror
Running "rm -rf /" Is Now Bricking Linux Systems (phoronix.com)
An anonymous reader writes: For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
Seems like the kernel is the wrong place to solve this problem.
So, which is it .. UEFI is catastrophically broken, or the way it's implemented is clueless and naive?
Because this sounds so horribly broken it isn't funny.
Actually, no, it's actually quite funny in a big giant "WTF" kind of way.
Lost at C:>. Found at C.
It's just now bricking systems? Wow, all this time I could have been running "rm -rf /" with reckless abandon ...
Yeah but viruses and spelling mistakes do actually happen.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
Have you tried not running rm -rf /?
Just an idea, but perhaps someone should set up a database that accepts failure reports and, consequently, shames all the hardware devs into fixing their (U)EFI implementations.
While I don't agree with mounting efivars rw by default, accidental deletion shouldn't permanently render one's computer an expensive piece of Lego.
I always run sudo \rm -rf That is the way to do it, you whippersnappers.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
...Systemd developers have rejected mounting the EFI variables as read-only...
So the sane solution is rejected because the underlying design is bad?
Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?
Those who do not learn from commit history are doomed to regress it.
What happened to booting from CD/usb? How about bringing up a system where all batteries are dead, so there were no power for bios stuff? The latter was a hassle, but you could always get those things going before.
I have full backups... it would be nice to know that I could use them to restore the system and keep going if I ever ran that command by mistake.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Note that the whole *nix way is 'everything is a file'. So to have it off in a hidden namespace would run counter to that philosophy.
Of course, historically things like devices and such have been special non-regular files. That way rm /dev/sda doesn't do anything freaky. It may be a good idea to rethink firmware data being modeled is plain files, but still be in the discoverable filesystem namespace.
XML is like violence. If it doesn't solve the problem, use more.
No, because the problem isn't systemd, it's UEFI.
Deleting your entire hard drive is not the same as bricking your device, Captain. Or at least it should not be.
While not running systemd is always a good idea, it wouldn't change anything with regards to this, as the EFI variables are in /sys/firmware/efi/vars regardless of what init system you use.
You wanted the "everything is a file" UNIX approach*.. well, you got it, including the ability to delete *every* file.
Incidentally, while systemd was being blamed for this, the underlying /sysfs structures have zippo to do with systemd, so put down the pitchforks.
* Which has never actually been completely true but is a popular catch phrase.
AntiFA: An abbreviation for Anti First Amendment.
No, I wouldn't expect rm -rf to brick my system. I would expect it to remove everything, and then I'd have to reinstall. I would not expect my computer to become unusable to the point that I couldn't reinstall an OS.
It always fried your OS. But now it apparently also destroys your motherboard if you can't reset the UEFI somehow.
This seems irrational:
"Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, "
Can't you just mount read only anyway? Fuck the broken apps. Does every system have them? It should be my choice but systemd devs are arrogant assholes. Are these "valid use cases" universal?
If Gentoo is ever systemd only I'll be done with Linux.
The
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
They have a point. The whole point of them being mounted is for utilities like efibootmgr to be able to use them.
There are two parties to be frustrated with: /dev/* all day long, and not actually affect any of the referenced devices). Should have made removal be a special ioctl, even if otherwise normal files.
-Firmware developers, for not being resiliant in the face of such shenanigans
-The kernel efivars implementation: for modeling these things as plain files with 'rm' meaning delete from firmware (you can rm
XML is like violence. If it doesn't solve the problem, use more.
Depends on the level of disaster you're expecting. You'd expect it to wipe the filesystem, however you'd expect to be able to reinstall afterwards. This story seems to be saying you can trash your UEFI BIOS in a non-recoverable way, and I certainly wouldn't have expected that (probably because I have no clue about UEFI).
The kernel dev who wrote the efi code says it's not a systemd problem and following the bug report's suggestion would be the wrong way to solve the problem.
But don't let that stop you from jumping on your favorite whipping boys.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Having come up during the advent of computers, this is PRECISELY why we separated hardware bootstrap firmware from user-accessible code in the first place, and did not make provisions for user-space access to change it. The hardware had to continue to operate and boot regardless of the stupid things users and developers did.
That all went out the window the moment we started with this "update your BIOS from the O/S" bullshit. And now, apparently, "let's give userspace read/write access to the bootstrap firmware willy nilly," which is complete and utter stupidity.
No, UEFI doesn't read variables off the disk, there's a kernel module that understands EFI confiig flash space, and exposes the data. Removing files from that pseudo-filesystem is like nuking the config flash area. Note firmware should still be able to tolerate this in theory, but it's not just 'some files got removed'.
The most robust answer is that efivars should not interpret unlink() to erase from flash, instead offering some special ioctl() so a calling program can say they *really* mean it.
XML is like violence. If it doesn't solve the problem, use more.
You could've avoided it by carefully using apt flags, but again, you're a fucking idiot.
A user shouldn't need to do that. It should be smart enough to know that other things are using it as a dependency and be smart enough not to remove those things.
It's a shitty design.
Except in windows, you have to be pretty intentional about it. Format C: or recursive delete of all of the drives would not cause this to happen. You have to be on a mission to screw up the system then.
Of course, that's still an issue, but nothing new. Most anything that allows it's firmware to be updated can allow folks to screw it up. All BIOS implementations could be screwed up by a knowledgeable person seeking to inflict pain. The new part is where Linux kernel modeled this data as regular files where unlink() is taken in a vary dangerous way.
XML is like violence. If it doesn't solve the problem, use more.
I'm a little surprised that motherboards don't keep a tiny read-only repository of code to restore from in case you FUBAR the writeable parts. Isn't BIOS code measured in KB? That's trivial space to devote to brick prevention.
The problem is less UEFI, more kernel design decision meets occasional real world scenario.
You could do this by writing to CMOS in BIOS. You could do this by writing junk to the BIOS flash space. You just couldn't do so accidentally, and vendor to vendor proprietary interfaces meant the knowledge was less common.
The answer is not to revert to the bad old days of no interoperable access to firmware configuration, but to rethink the interface to avoid this sort of accident.
A follow up is for vendors to explicitly test loss of all EFI variable space that their runtime services allow to be removed.
XML is like violence. If it doesn't solve the problem, use more.
There are too many imbeciles that will brick their system by typing in random terminal commands they found on the Internet, like fork bombs or using wget to download a trojan. rm -rf / is only the most famous of this kind of command. Then they will complain that Linux is too fragile and dangerous to use for new users, blah blah blah.
I was thinking of a possible solution to this. Perhaps the distros meant for newbies (Ubuntu, Mint, elementary, Zorin, etc.) could lock by default the most well known terminal commands that fuck your system up. When trying to execute them (even with root privileges), they will get something like "ERROR: This command is extremely dangerous. To execute, go to [distro's website].org/foobar." This page will have the password in order to bypass the lock, but only at the bottom of some text that explains exactly what will happen, and if you do anyway, that the distro has absolutely 0% liability to what will happen to your system.
How about you can the fucking idiots who modded this shite 'insightful' read the summary and TFA - or is that too much to ask? Silly me. It's Slashdot.
And you're more of a fucking idiot.
There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).
No sane package management system would do things this way.
This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.
Whoosh. This shouldn't brick a system.
No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI. Linux package managers are well overdue for redesign. Making hardware brick able by software is also bad design. Mounting firmware as ordinary rw files, ditto.
And its by ignorant design mostly
for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt
say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire
I'm not a fan of the Debian packaging system but it's not that bad. You must ether have done something really wrong or you are just really bad at trolling. For one thing apt-get tells you what it is going to remove so if you blindly accepted you have only yourself to blame. Secondly I'm having a hard time believing that apt-get would actually uninstall that many packages for such a trivial program.
Seems to me that this can be alleviated with selinux. Deny all write access to those paths except when in an explicit context, which the few tools that need that access will have, and even root will have to newrole into to use.
See the subject line.
Obviously this poster has no idea
1. of what he is doing
2. that XFCE in Debian is not "Linux"
But Linux was working, right? So it didn't fuck up Linux, nor the base Debian/Ubuntu install. It fucked up XFCE, which is something that is an unfortunate side effect of having the user interface as an uninstallable add-on. The fact you use XFCE on Ubuntu means you chose that desktop environment by choice. Would you rather Linux make it easier for you by forcing you to use KDE 4.0 (or Gnome 3), say, so that it can't be uninstalled by accident?
Those who do not learn from commit history are doomed to regress it.
Yes, malware is probably the biggest real danger here.
That said, over the years I've also seen my share of very sheepish-looking engineers whose scripts didn't guard against an empty environment variable...
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
And you're more of a fucking idiot.
There is no reason to suppose that removing a game should remove much more than the game (maybe a library or two used only by the game, but that's it).
No sane package management system would do things this way.
This has bit me too, but I noticed that the list of things to remove was way longer than it should have been and stopped it, but it wa something like remove a small application and have it want to remove things that were fairly important.
The very first distro I used was Xubuntu. And like our GP, I wanted to remove some of the unnecessary games that came with the distro, so I too used sudo apt-get remove in order to do so. And I have absolutely no recollection of the entire DE being dependent upon sudoku. So it sounds like the GP is just making shit up. Even if he wasn't, he was still a numbskull, but he probably did make it up.
We're not talking about hosing the OS. We're talking about hosing the motherboard.
Linux is anything but fragile. Stop blaming the OS for a shitty design in UEFI! Linux is so stable and solid that it lets you run "rm -rf /" and it will actually do what you asked it to until it can no longer figure out the machine it's on and commands needed to talk to a disk. This is a more than 45 year old design. Yes, that's right. In AT&T's original Unix you could also kill a system with "rm -rf /".
'but', 'but', 'but', oh shut up and stop spreading FUD! "rm" is the remove command, "-r" is recursive, and "-f" is force. You need to be root to run this with any success, so it's not like any old user can remove everything.
The problem is that UEFI allows an OS to write to areas which it should not be able to write to. If you open all the PROM in a system it's not just the OS that can brick a system. A malicious person can do so just as easy, and without being so obvious as running "rm -rf /"
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
I've read a few things about systemd that are not entirely positive. There seems to be a religious war about using or not using (and whether it should be optional). The thing is, hindsight is 20/20. When Linux was first conceived (and MS windows for that matter), no one foresaw anything like UEFI. How could they? Well..maybe if you were Nostradamus, but I'm not sure even he predicted this one. (anyone care to check his notes?) A living growing system must adapt to it's environment to survive and Linux (and MS Windows), are "living", growing, changing, evolving system. This is all part of the process. I just wonder how long before some genius says "hey, how about a new status on certain file/file locations that has an additional sudo like layer so people have to confirm this before they potentially nuke a UEFI system"). I'm sure it will happen eventually (hopefully very soon, we've had time to consider this...). I remember reading, "Make an idiot proof system, and the universe will build better idiots.". We'll get through this. Of course deleting things recursively is a dangerous operation and perhaps this is a sign that we should all stop being lazy and remember that "with great power comes great responsibility.". :D
"Imagination is more important than knowledge" - Einstein
You have to be pretty intentional to run rm -rf / as root...
Those who do not learn from commit history are doomed to regress it.
"rm -rf /" doesn't reformat anythings. I only deletes files, from all mounted partitions, including any mounted network share. It's not the same as mkfs.ext4
Exactly. The real problem here isn't that root can do stuff. The real problem is that root can do stuff accidentally by sneezing five metres away from the system at lunchtime.
Of course, the other real problem is that anyone is crazy enough to make hardware/firmware where you can delete essential data like this and have no recovery or at least factory reset mechanism, regardless of anything the OS might be doing. People making hardware vulnerable to this should be getting named and shamed as well.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
XML is like violence. If it doesn't solve the problem, use more.
No you don't.
rm -rf / tmp/throwawaydir
XML is like violence. If it doesn't solve the problem, use more.
*sigh*
Read the fucking article before you make an ass out of yourself. Hell, in this case, the difference between "OS doesn't load" and "computer is bricked" is clearly explained.
This doesn't apply to VMs I hope
Linux package managers are well overdue for redesign.
I'm sure Pottering will oblige in due course.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
It makes perfect sense for a format of my drive to brick my entire system, that makes perfect sense, in 1968. My bad, I thought this was 2016.
Really? How come your system doesn't say you don't have permission to delete / ?
Those who do not learn from commit history are doomed to regress it.
Which distro was it? Ubuntu, Debian, Mint, another? It could be integrated as a gnome dependency but that seems strange. There are many flavors and it's possible not all of of them do this (I may try on virtual OS's just to confirm). Yes, it is illogical, but being open source + community driven, we have the ability to change it, either in code for submissions, or in bug reports. The thing about MS (Especially Windows 10 which sends data about you which is hard-impossible for a non-techie especially in Home edition to block/shut off and even Windows 7/8 may have their systems hijacked if they don't disable Windows updates in the "Services" and now there is no description in new updates so you have no clue what they are doing until it's too late..), is if the community says something is bad/irritating, MS says politely "f** you". With Linux distros, you have a chance of being heard. The only way MS hears anything, is if given an "offer you can't refuse" by the US government, or if everyone stops using MS Windows. (which while there is chance is happening with more Android/iOS/MacOS/Linux users leaving MS in disgust as they realize there ARE choices), is happening at a snail's pace. So it's your choice: Go with an OS where your opinion might matter, or with an OS that couldn't care less because they still think you are beholden to them.
"Imagination is more important than knowledge" - Einstein
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
Note I've never actually done this, but I'm just saying I can see how someone could end up doing it. Most of us may know better, but that smug sense of knowing better doesn't really help those who will ruin their day beyond any ability for them to recover.
XML is like violence. If it doesn't solve the problem, use more.
and yet every single "how to do X in linux" tutorial starts by telling you to open a terminal and type sudo XYZ
Are you sure you want to say every single? Because that leaves you open to a lot of counter-examples wrecking your case.
His point was the act does not have to be intentional - never underestimate the power of a finger fuckup... especially when logged in (or using sudo) with enhanced permissions.
IIUC, so that when you remove the character device it doesn't allow and unlink to reach the UEFI? Is that the implementation issue you mean? Surely the kernel can abstract the access to UEFI to allow writes to pass and just remove the character special device on an unlink so the machine still boots the hardware.
I do rm -rf / more often than you would think. Sometimes I deliberately fail systems this way while they are running so I know how they fail when I loose a filesystem with a running application, it helps identify what is happening if I see the same thing occurs on live systems. It doesn't mean I want to trash the test boxes though.
This kind of explains some hardware failures of some hypervisors we had last year. We were scratching our heads at how voltage spike could take out two machines the same way through 10 of thousands worth of power conditioning gear whilst they were powered down, they both had corrupted UEFI bios, everything else was fine.
My ism, it's full of beliefs.
Oh yeah, heaven forbid you want to uninstall the built-in crappy calendar orage. It's a required of the xfce desktop. You kill it, your desktop is GONE.
I'm just curious what OS you think *isn't* guilty of this. Guess what happens if I try to uninstall the taskbar from Windows or the Apple menu from OS X? Oops, my whole GUI is wiped out; the OS probably wouldn't even boot at that point.
When I hear Bricking it means I have to toss the hardware or whip out a JTAG or EEPROM programmer.
Is this "bricking" real or just someone not understand what the word actually means and a initialize and reinstall of the OS will fix everything.
Do not look at laser with remaining good eye.
Yepp, Some package managers are on crack too often.
Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.
We suffer more in our imagination than in reality. - Seneca
I wonder, why don't they just provide a configuration setting for this? Then everybody can decide what they want. In the kernel, this works super well. Not just on the build system level, but also on the config level once the kernel is built. Take sysrq for example, its a similar situation. You can use it for malicious purposes like killing a lock screen, but if you don't care you just edit /proc/sys/kernel/sysrq, and you get back the old functionality. And some distros even provide a file in /etc which is read at startup so that the change is persistent.
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
A particular example of this is some nasty rootkit that comes (came? Not sure if they still do this) with Adobe Acrobat for Windows. The purpose of the rootkit is (was) to prevent people from pirating the software, but if it was tampered with or improperly deactivated, it had a tendency to throw a wrench into the entire booting process.
I wouldn't say it's as obvious as you make it seem. There is a difference between erasing the entire file system (obvious) and bricking the hardware by destroying the firmware.
I never run rm -rf /. But when I do, I
[Connection lost]
You also need the "--no-preserve-root" and to have a buggy motherboard UEFI implementation. The problem is that deleting stuff in /sys/firmware/efi/efivars resets some variables in the UEFI. If the implementation follows the spec then that is like doing a factory reset on your motherboard. For some poor hardware they fail to boot after this. The kernel already has some protection for some bad hardware, more will be added shortly ( https://gist.github.com/mjg59/... ).
I ran into this UEFI crap about half a year back, when I had to adjust some BIOS settings and couldn't, because I didn't have windows installed. I couldn't believe it. RMSes worst nightmares come true, today. Un-fucking-believable.
UEFI is just another machiavellian attempt at controlling our hardware from start to finish. It's basically the old TCPA bullshit repackaged. How the fuck anyone could install let alone design and build a BIOS whos UI is depedant on what OS is installed on the HDD is totally beyond me. I honestly am of the opinion that those who designed this freakin' insane UEFI BIOS crap and peddle it should be brought before court for malicious malpractice and willfully undermining computer security.
UEFI in my book is definitely a reason not to buy the hardware using it.
BTW: How come no one get's worked up about that? Everyone is pissing their pants about systemd, but UEFI doesn't get half as much bad press. I remember the TCPA uproar - that was a good one. How about now?
We suffer more in our imagination than in reality. - Seneca
Most/all recent versions of rm on Linux/BSD/OS X will refuse to remove the root filesystem without the flag -nopreserveroot.
It actually does have to be intentional at this point.
> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
Jesus I thought we'd gotten rid of that stupid "brick" term for simple issues. If it's a COMPUTER - you can't "brick" the damned thing if you take the hard drive out and throw it in a river.
"Bricked" indicates that the firmware is bad. A bad BIOS flash will brick a system. Something of that level. Anything that can be fixed via an OS reinstall ain't "Bricked".
"People who think they know everything are very annoying to those of us who do."-Mark Twain
I wasn't being smug. I was noting that doing something as specific as that while running as root is on par in intentionality as your Windows example. Your comment wasn't helpful either, to say that it's harder to do in Windows.
Those who do not learn from commit history are doomed to regress it.
Except in windows, you have to be pretty intentional about it.
Yeah, so? I wouldn't doubt there are some bad guys who have some intentions to do it.
I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Just mount them RO by default, require the user to remount as RW if they need to run one of the applications that actually needs RW permissions. This has been done for other critical filesystem components on various Linux distributions since forever.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Firmware developers, for not being resiliant in the face of such shenanigans
The firmware guys didnt ask that its contents be exposed as just another generic part of the storage hierarchy. Its supposed to be Handle With Care.
"His name was James Damore."
My point is that logging in as root or typing sudo and a password is intentional. You can't accidentally get root permissions. That's why they exist.
Those who do not learn from commit history are doomed to regress it.
The replies to this comment are why a lot of level headed people who don't use Linux, never will and those who do, won't use Internet forums.
Sig missing. Reward.
Sorry, but the package manager's behavior in this instance is indefensible. It absolutely positively shouldn't fuck with XFCE just to remove an app.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
for example last night I removed the soduku game that came with my distro, thanks to its dependency tree and debian / ubuntu's package management removing this one stupid game took half of XFCE with it, and I was left with a command prompt
Which distro, and what system did you use to tell it to uninstall the package? And did you file a bug report?
say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire
Neither does Linux. I've never had such a thing happen. I've had plenty of fucked windows installs on the other hand...
SJW n. One who posts facts.
While that may be true, most systems don't use SELinux, and for fairly good reason if you ask me. I've tried a couple of permutations on the idea, and having several parallel security systems has never really come out as a good thing in the end. Especially one as complex as SELinux.
... hitting yourself in the head with a hammer may cause headaches, or unconsciousness.
Why don't we just set the contents to these to immutable (by default) and if there are legit reasons to change values through software, just add the subroutines to flip the bit back and forward and verify, etc. Done.
chattr +i for those who are not aware.
Sig missing. Reward.
Of all the things you could run that you might expect to 'brick' your system surely 'rm -rf' as root would be the one.
Consequences arise from actions. I hate UEFI as much as the next guy, and don't get me started about SystemD but this looks like click bait.
Damn, got me.
Well, it's kind of clickbait, but its proper nerdish clickbait. It's even a sort of test, if you will. While the systemd haters will automatically jump on another chance to rail on about it, anyone who reads the article will see that it isn't a systemd problem, its a UEFI fault. Because you can make the same thing happen in Windows. A little "harder" and no doubt, but systemd could be wiped off the face of the earth, and not fix the problem.
New Geek meme : Thanks, systemd!
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Windows and OS X on the desktop are also jokes because when I accidentally (read: recklessly type shit into the command line) remove software, I get all sorts of problems.
Also, trucks aren't ready for the road because when I tear out pieces of the engine nondiscriminately, sometimes it doesn't turn on anymore.
Sorry, but the package manager's behavior in this instance is indefensible. It absolutely positively shouldn't fuck with XFCE just to remove an app.
Rest assured that the GP is probably full of shit.
Yepp, Some package managers are on crack too often.
Debian Stable removes the network stack by default if you uninstall the Gnome GUI. Fucked up my day when I was doing a server-install and just wanted to ditch the GUI as a last move. Since then I always leave the GUI installed - even though that's actually pretty retarded for a Linux Server Host. ... But that's Debian for you.
That's because the network stack is built into GNOME, considering it's meant to be manipulated through its GUI. You could've prevented this by (1) checking what you were removing before you went through with it [as apt will clearly warn you of], (2) keep a secondary network stack installed in fact the first malfunctions, and (3) using system snapshots as something to rollback to if you're displeased with some changes you make.
Not so easy to remove the hard drive or re-install the OS from scratch remotely. The problem people are encountering is that they are physically thousands of miles from the hardware.
I mean, for the last 10 years, I have worked on a computer I've never seen. The Mainframe is in Delaware, and I am in New Jersey.
But I can easily imagine a situation where I'm in Manhattan, but the Linux machine is located in a data center in New Mexico, or even worse, Mumbai. Effectively, I have zero access to the hardware, so yes, in such a situation the machine is effectively "bricked".
If telephones are outlawed, then only outlaws will have telephones.
Why is SysFS deleting/erasing variables/files on RM? /dev/null by accident right?
Can't these be handled like special device INodes?
It is not like you can delete
Léa Gris
While that may be true, it could be considered an attack vector. We have been focusing on accidental corruption, but it makes for a pretty mean thing to do to some poor saps hardware. Resiliency in the face of such a condition is not too unreasonable, it's just a test case that hasn't really been pursued to date. UEFI having missing configuration should be easy enough for code to cope with.
XML is like violence. If it doesn't solve the problem, use more.
I can't think of another single instance of hardware/firmware entity being modeled in just such a way. The whole 'devnode' concept serves to segregate some of this special stuff away from common filesystem operations using special ioctl calls. I know they are a tad more annoying to deal with than a totally regular file, but it's not that terrible.
XML is like violence. If it doesn't solve the problem, use more.
nuff said
Have you even read the article?
Are you going to block rm -rf /sys/firmware/efi/efivars too? In fact are you going to add filters for everything that the rm command is not supposed to delete? How about the > command then. What if you did > /sys/firmware/efivars/* ? Would you block that too? How about the cp or mv command? dd? echo? cat? I could easily come up with some destructive stuff using those commands. Good luck with preventing all that.
And even if you could change all your shell utilities to block all potentially destructive modifications, it would still not prevent a rogue program or an attacker who gained root on your system to run their own code and permanently brick your system.
Read that carefully: permanently. brick. your system. Not: oh shit my linux is broken, I have to restore from backup or reinstall, but: oh shit, my motherboard is fried and I have to buy a new computer.
This is dangerous stuff, and it is something new to take into account when playing around with your computer. It used to be that nothing you did in software could damage your hardware, and there was something liberating about that idea. This has now changed.
That doesn't mean that a *lot* of people run fast and loose as root. It's a very bad practice, but it shouldn't be *this* bad.
XML is like violence. If it doesn't solve the problem, use more.
Boy, Windows is so advanced that it fucks itself in the background, while you use it - no need to uninstall solitaire.
say what you want about windows, it doesnt fuck the entire system if I uninstall solitaire
They do that with updates.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Of all the things you could run that you might expect to 'brick' your system surely 'rm -rf' as root would be the one.
No, you'd expect 'rm -rf /' to hose your linux installation, maybe your data too and require re-installation or restore from backup. That doesn't qualify as bricking.
"Bricking" means corrupting the firmware held in non-volatile memory on your device so it can't be revived without specialist reprogramming equipment - this usually only happens if you botch an attempt to re-flash the firmware.
The term has been watered down and abused as click-bait in the past, but this sounds like the real deal: the claim is that 'rm -rf /' can now permanently erase part of the firmware and make it non-trivial to restore your system. I guess YMMV depending on your motherboard's BIOS-flashing facilities.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
To AmiMoJo: Sorry for the wrong mod.
Third comment on the bug:
Watch this Heartland Institute video
A while back I installed Debian on an experimental system for learning more about Linux, and came away feeling a bit lost, because (compared to some other distros) there seemed to be oodles of new config files, scattered everywhere. Trying to keep track of them all was, for me, nightmarish. I wished all the config files were located in a single root-level directory (like "home"), perhaps named "cfg".
Well, if such a thing existed, that directory might be considered too valuable to be allowed to get included in any generic remove-all system command, and could thus be a safer place for the UEFI variables. One could go inside that directory and deliberately erase everything, but the specter of knowing that all the system's config files would be destroyed might give one pause,before daring to actually specify that command.
Wouldn't the best policy be to simply not let rm propagate through mounted filesystems beyond the initial filesystem, other than to basically cause an unmount condition prior to deleting the mount point itself?
Do not look into laser with remaining eye.
I've managed to mess up systems real badly by using aptitude and blindly accept conflict resolutions that involved removing and downgrading packages (or leaving dependencies unresolved). But that only happened because I thought I was smarter than apt-get (package xxx could not be installed? Bah! aptitude will fix that)...I had backups anyway.
I've never seen systems get messed up because of trivial apt-get operations otherwise (dist-upgrade between different versions is always hit-or-miss, though).
I have, however, seems windows systems become stuck in a reboot loop after a routine windows (critical) update, which is no fun to solve because you don't even get a console, or logs or anything. Not even live CD with some basic rescue utilities. Knoppix has saved my arse countless times in those situations.
I've also seen Windows get 'bricked' after an update as well as 'OS X'. That's 'bricked' from a normal user's point of view, I could usually fix the problem but then I have a CS degree. The same has happened with Linux boxes (i.e. 'bricking' that was fixable with a high degree of computer knowledge) but it's quite rare that it's so bad I can't even boot to command line. These days the most irritation I get from Linux is annoying glitches and bugs that are mostly due to poor quality control but that also depends on the distribution. Some distributions are way better at quality control than others.
Well that's just not true. IBM PowerPC and Sun Systems hardware had firmware for a very long time. x86 was way behind the curve on this one, and firmware was well understood by then. Perhaps UEFI has its own quirks, but it was hardly novel.
Higher Logics: where programming meets science.
guess what, I used the little ubuntu software center to uninstall it
xbubtu and the ubuntu software center
UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.
Right now the efi variables are normal files: /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
$ ls
-rw-r--r-- 1 root root 57 Jan 22 09:58
So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.
The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.
XML is like violence. If it doesn't solve the problem, use more.
In practice, you can't avoid it if you want to use the most common userspaces for Linux. The average user won't care about its presence per se.
And his point is still not about whether your root permissions are accidental or not, its the accidental space between the '/' and the rest of the path, meaning you end up with 'rm -rf /' bring run, with some garbage data on the end.
The command being run is not the command intended to be run...
There's no should or shouldn't about it though. It's the root account. By definition, everything the system allows you to do is achievable from that account. The argument should not be "it shouldn't allow you to do that even as root", but "there should probably be higher privileges below root rather than making people go all or nothing". I would agree with the second argument, but I'm the one making it.
Those who do not learn from commit history are doomed to regress it.
There are various options to do just that on various utilities, but the status quo is that they are not default.
The 'you really didn't mean to remove root, did you?' in rm already should provide a measure of protection against the 'rm -rf /' case specifically, but it's a convenient shorthand to denote a failure scenario that could be reasonably mitigated without too onerous of an interface for things looking to use the efivars correctly.
XML is like violence. If it doesn't solve the problem, use more.
first
rm -rf /first/*.*
By the by, the above 'code' snippet may well brick a *nix box - use at your own risk. I saw first-hand that doing an rm -rf *.* was perfectly capable of blowing away an entire install (including all mounted devices), no sweat - at least as late as 2006 when a junior admin I once worked with made that rather horrendous typo in his regex...
But overall, why the hell is this news? I mean, every OS has this problem (see also the ancient deltree, or the newer rd /s, or getting stupid with the GUI Disk Utility in Windows or OSX, etc.)
Boys and girls, this is why you don't give ordinary folks admin/root/wheel/whatever privileges, eh?
Quo usque tandem abutere, Nimbus, patientia nostra?
At what time would I ever use 'rm -rf /'
After accidentally hitting return partway through typing 'rm -rf /something/you/actually/wanted/to/delete'; running a shell script with 'rm -rf $MYPATH' where $MYPATH had got set to '/'; by installing malware and giving it the admin password or some other equally stupid screw up.
If you are omnipotent and infallible and never have, or never will, make a stupid screw-up like that (or run IT support in a perfect world where none of your lusers can pull rank and demand admin rights on their PCs) then all well and good. Otherwise, the consequences just got raised from restoring the hard drive to replacing the motherboard.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
cd /tmp
rm -rf throwawaydir
FTFY
guess what, I used the little ubuntu software center to uninstall it
And what version of Xubuntu was this?
I've had that happen before, many years ago, with some other bit of software. You have to have the package manager remove old dependencies that it thinks are no longer required. Here's someone on the Ubuntu forum with a similar issue: http://askubuntu.com/questions...
I imagine the GP was trying to free up some space so asked for old packages that were no longer needed to be removed, and the package manager just decided to delete everything it had previously marked as no longer required. The correct behaviour would be to re-check all dependencies first, which I'm sure you can manually force somehow but that doesn't excuse this.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
And MY point is that it IS about whether your root permissions accidental or not. I can type rm -rf / tmp by accident right now and nothing would happen because I AM NOT ROOT. I simply cannot trash my hardware in that way without first having intentionally logged in as root or sudo. The comparison is simply moot.
Those who do not learn from commit history are doomed to regress it.
I think the transition of malware from mischief to profit puts a stop to that. I can change voltages on my motherboard with a software utility, if someone wanted to cause hardware damage they could easily do so in malware.
Xubuntu 14.04.3 LTS
*pay some fucking attention when you see more packages marked as remove than you bargained for and use ctrl+c to kill the apt-get command before it completes
I tried that once and it was pretty much the equivalent of shooting my package manager in the head. I ended up with a number of packages with conflicting versions that it couldn't figure out how to resolve, and I didn't know how to fix.
Don't do that unless your beard is sufficiently long.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Yes, and that completely ignores the question.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
Obviously you can type. Go look it up on Wikipedia.
The design of systemd has ignited controversy within the free software community. Critics argue that systemd is overly complex and suffers continued feature creep, and that its architecture violates the design principles of Unix-like operating systems. There is also concern that it forms a system of interlocked dependencies, thereby giving distribution maintainers little choice but to adopt systemd as more user-space software come to depend on its components.[64]
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
This is so boneheaded it beggars belief. The straightforward solution is to require the UEFI variable filesystem (or whatever it is called these days) to be mounted read-only, and require (UNIX anyway, but something analogous ought to work for Windows too) an application to do a "mount -o remount,rw" to do whatever it needs to do, then do a "mount -o remount,ro" when it's finished. Not as nice as having UEFI not be seriously broken, but workable, and there's not much of an excuse for things like systemd, openrc, etc. implementing this where appropriate (and for any UEFI crap that can brick a system, this is appropriate).
Applications don't like it? Tough, patch the damn things. Requireing firmware to be exposed to harm like this on any operating system is unacceptable.
The Future of Human Evolution: Autonomy
On at least Windows 7, you can get rid of the shell and it will still boot. You can open task manager with CTRL+ALT+DEL and launch programs. When you minimize a program, it goes down in the corner as a little bar just like it did in Windows 3.1
As late as XP, you could set progman.exe as your shell...which was weird.
Boot partition? You have no idea what you're talking about.
an rm -rf / will wipe EFI vars as well. The motherboard will not boot anything, regardless of what is on your drives.
Mounting UEFI variables as read only breaks things too
"His name was James Damore."
Xubuntu 14.04.3 LTS
OK, now I know you're full of shit. There's no dependencies on sudoku in Xubuntu 14.04.
Tried it in the software center, too. There's no dependencies.
And how is still systemd's fault?
Those who do not learn from commit history are doomed to regress it.
Why can't it be mounted as read-only, and remounted as read-write when necessary? Something like "mount -o rw [mount_point]" does that job.
On at least Windows 7, you can get rid of the shell and it will still boot. You can open task manager with CTRL+ALT+DEL and launch programs. When you minimize a program, it goes down in the corner as a little bar just like it did in Windows 3.1
As late as XP, you could set progman.exe as your shell...which was weird.
I didn't say crash explorer and dwm, I said uninstall it.
If the BIOS isn't even robust enough to use defaults for critical variables that can be deleted, then I'm gonna say this is OBVIOUSLY a problem with crappy BIOS code, not with the OS that ran the app that actually did exactly what it was told to do.
> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
I can confirm this is the case: http://s23.postimg.org/yxo666n...
I didn't say crash explorer and dwm, I said uninstall it.
You said uninstall the taskbar. The only way to uninstall explorer.exe is to delete it and set the shell to something else (or blank). Windows will still boot. DWM isn't responsible for the task bar and has nothing to do with the discussion.
I have to agree. Although none of the parties involved are fully responsible, this combination of factors produces a very nasty situation. At the very least an attempt to delete files of this sort should generate a warning and confirmation dialog or require a special switch of some kind.
While that may be true, it could be considered an attack vector.
Major parts of all modern operating systems are dedicated to reducing attack vectors. Even main memory has an OS gatekeeper.
While I sit here wondering why the fucking bios variables dont have an OS gatekeeper, I find it a bit alarming that instead of access restrictions there is in fact a red carpet.
"His name was James Damore."
all I can tell you is that was the only thing I uninstalled, rebooted and im at a command prompt
all I can tell you is that was the only thing I uninstalled, rebooted and im at a command prompt
Show me your syslog and I can tell you what happened. But your anecdote, as reported, is inaccurate: uninstalling sudoku had nothing to do with your DE getting fudged.
At what time would I ever use 'rm -rf /'
Addendum: see the first example here!
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
I always tell new admins to type the path being deleted first, then type /bin/rm -r at the beginning of the line. Those pesky / and \ are too close to the enter key. Especially a problem for Windows.
Thank you! This is the informative response I was looking for. I was not actually trolling (this time) but I knew I'd probably be down-modded as such anyway.
Though, that doesn't account for why the /sys/firmware/efi directory isn't even present on my system.
Assuming you mean Ubuntu Snappy, kinda. The transactional updates will let you roll back changes (which is awesome) but it doesn't really fix the fact that package managers shouldn't be doing stupid stuff like that in the first place. The new package managers coming out of the major distros should hopefully fix a lot of the problems with the old ones.
It's a little worse than that. At least on Ubuntu, the package manger is pretty aggressive about removing old stuff. When you install or uninstall a package it mentions that it found all this old cruft, and would you like to remove it (Y/n)? A regular user is pretty likely to just say yes. You don't need to specifically be trying to free up space.
It used to be done on purpose on sacrificial systems to show how processes stay resident in memory. Now they have to be really sacrificial.
Couldn't PAM be configured to prevent "rm -rf /" ?
It might be for the benefit of non-technical users who don't understand that the chat or forum user recommending sudo rm -rf / is up to no good. At least if the system is bootable from install media, the user can restore /home from backup.
I doubt very much he told apt to remove his window manager. The apt system (either apt itself or some Ubuntu package(s)) has some buggy bits that don't do so well keeping track of dependencies. As someone else pointed out, this is probably the code that looks for unneeded libraries. The OP wanted to remove his game, but apt said "by the way, here's some other stuff I found that you don't need anymore, want me to remove it?" and the OP hit yes (sounds like a good idea, no?).
You can't do the same thing in OS X. I don't know about Windows. The app store can't remove or modify system files unless you're explicitly installing an OS upgrade.
In general, programs on the Mac are much more self-contained, at the expense of a bit of replication of libraries. The OS X bundle/framework paradigm is excellent, and well worth copying. I'm not sure what app store Windows does, but in the past this kind of problem in that OS was known as "dll hell." Linux has much of the same problem, and the currently implemented fixes are pretty clunky.
Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?
It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.
As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:
And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:
Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.
Hire a Linux system administrator, systems engineer,
I use dd if=/dev/zero of=/dev/sda instead.
rm -rf /first* is sufficient. Why the *.*? There is no need to remove only those with dot and in the first subdirectory. If you believe you need to match the dot otherwise the * will match only everything before the dot, one day you will be in deep trouble.
Achille Talon
Hop!
In most cases, electronic devices should be able to be reset back to a factory state by their owners, preferably with a hardware switch that cannot be disabled by any software.
Exceptions would be for things like car-odometers/disk-drive-power-on-hours logs that need to be kept for fraud-prevention or things that the customer himself doesn't want to be re-settable, like anti-theft protection.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
No. rm -rf / means reinstall or restore from backup. The non-obvious part is that your motherboard may never boot again.
Except he is in fact a liar. As others have confirmed in this thread, removing sudoku via apt-get does not remove xfce. In fact it doesn't remove anything but the actual sudoku app.
So I'm sure he issued a bunch of other apt-get commands he has conveniently forgotten to mention here because he had no idea what the hell he was doing, and then he goes on to blame Linux and apt-get for his own willful ignorance.
The *.* catches the '..' , causing the rm command to jump up a directory (eventually to / ).
Quo usque tandem abutere, Nimbus, patientia nostra?
I can see this happening, MAYBE. But only because he installed all the dependencies when he also installed the game. When he tried to uninstall the game, it took all the dependencies that were installed when the game itself was installed. MAYBE.
That would be the ONLY case where I could see something like that happening. Again, MAYBE.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
The mental model of a file system - the expected behavior - is for it to be hierarchical. We silently expect anything below a certain path to be subordinate. Already this model is broken because devices can be mounted, files symlinked/hardlinked etc. That something much more fundamental to a system than a file system directory can be found deep in the hierarchy is a violation of the hierarchy.
That's why it is surprising that removing everything from the file system may cause higher order information to be deleted as well. You do not expect that. The impulse to map everything to a file deep in the filesystem is dangerous.
Sure, you can probably write/destroy UEFI variables from windows, but not as unintentional collateral damage from deleting a directory.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
No, the answer is non-bug ridden EUFI that has a simple sane way to return to factory settings if you wipe the variables. In the BIOS days, no amount of screwing up the CMOS settings would brick the board. Worst case you have to remove the battery for a moment to return to defaults and then re-configure from the CMOS menu. Most boards had a jumper for that as well.
You could brick it by erasing the flash, but that was in no way a usual operation for configuring the machine. Some boards even had a recovery path for that where it would boot from a protected backup flash.
Put a reset to factory jumper on the board and have EFI detect that and replace any existing variables with the factory default and the problem goes away.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
The standard test case for UEFI seems to be, "Does it boot Windows?" Those drivers tend to be really buggy.
"First they came for the slanderers and i said nothing."
Since a "few years", on "most distros", you need to pass --no-preserve-root to rm rf slash to actually do something.
Just out off office; too tired to look up exactly :
But a "few years" is about 3-5 years
"Most distros" means maybe >90% of the linux userbase
Some other unices got that new default, but as other unices are often older systems, i wouldn t bet on the userbase percentage
The answer is to include a way in the UEFI to restore the default configuration so something like this doesn't brick it irrecoverably.
Rethinking the interface would be nice, but wouldn't stop malicious users.
"First they came for the slanderers and i said nothing."
the question was "Why wouldn't I reformat the partition?"
The answer is that he can format his partition if he wants to, but the proper way to do it is not to use the rm command at all.
I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.
You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.
The problem is that systemd has put those variables directly in harms way. *Never* would you expect that removing all files from a file system would delete variables outside the operating system - in the firmware.
The file system is *owned* by the operating system, which is a subordinate of the firmware. The control chain goes: firmware > boot-loader > operating system > file system. For the file system to cause damage to the firmware is a design bug, even if the endpoints to do such damage has been exposed by the firmware.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Well I gotta tell you I've seen programs removed and suddenly the system would not boot on Win7. Seems the uninstaller took a few system files with it. Shitty developers can fuck up absolutely anything.
On Windows, uninstallers cannot delete system files. Since Vista, Windows Resource Protection has prevented even processes running as administrator or SYSTEM from changing/deleting system resources (files, registry keys etc). Only the "trusted installer" account can write those files, and only the WindowsUpdate process runs as trusted installer. It will not install 3rd party applications.
Not saying that an uninstaller cannot do other harm which could toast the boot process, but it cannot delete system files. Safe mode will trust *only* system files, and should always be able to load - bar hardware failures.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
He's already talked about doing so and I wouldn't be surprised if he's started. He wants to standardize pieces of linux that have been a nightmare of aging incompatible code. A natural stop on that path would be Linux package managers. As much as I love Apt-get, and I like emerge they all ultimately suck. They call it dependency hell for a reason.
Ultimately we'd all be better off if someone could figure out a better, more robust and more modern solution to Linux Package managers.
You make a good point, though it probably requires some degree of actual knowledge and skill, or at least a suitable malware toolkit, to cause damage by playing with electrical levels. Any script kiddie can do 'rm -rf /' and surely it's practically the first thing any mischief-makers will try.
It's still crazily easy to do this by mistake as well, though.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
You can't do the same thing in OS X. I don't know about Windows.
Windows has had Resource Protection since Vista. Even before that, Windows File Protection going back to Windows 2000.
Only Windows Update can run as "Trusted Installer" - and only trusted installer is allowed to replace or change system files.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I'm not going to change out my engine because tyres keep blowing, I'm going to stop driving over glass.
If there is a way to stop rm~ from killing a machine, if it's a situation I ever come across (I haven't had to think about it, to be honest, beyond noticing a system partition of 300MB on my notebook and thinking to myself "You know, that looks important, better make sure I've got a backup"), then I say thank fuck for Replay and shadow copies.
Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
The answer is that he can format his partition if he wants to because the proper way to do it is not to use the rm command at all.
Exactly! So to restate,
At what time would I ever use 'rm -rf /'
You just keep reiterating the question as if it's somehow the answer. Or by
"rm -rf /" doesn't reformat anythings. I only deletes files, from all mounted partitions, including any mounted network share. It's not the same as mkfs.ext4
did you mean
rm and format are two different things. You'd want to format in a situation where you didn't want to rm.
? Which isn't really helpful at all, but just a tautology.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
My Grandpa was very fond of one particular expression. From time to time, I would ask him what would happen if you did X, Y and Z, where such a combination was likely to result in a Bad Thing happening.
His response was usually, "Well, you just don't do that."
www.wavefront-av.com
I don't know that because it is a tiny little bit harder to do in windows, that it makes systemd the bad guy in a UEFI fault.
You can not accidentally write to those variables in Windows when trying to format a disk or do other admin work.
can write to those variables in Windows as something malicious.
The tap-dancing to make UEFI an open sore, ready to be exploited, the fault of Systemd, while using weak arguments to make it no problem at all in Windows says a lot. Not much of it very good.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Yes, UEFI should be implemented properly (and in fact there are a host of things to allow an implementor to properly protect data they could get broken by, if they can't be bothered to tolerate the data).
However, that's a criticism of vendor implementations of UEFI rather than UEFI itself. Of course one could say that UEFI being so complicated means it's harder to get right, and that would be a valid point. In this particular scenario though, all it would take is for vendors to have standardized on a data format in CMOS in BIOS, and the same thing could have happened in BIOS land (and potentially worse, since in UEFI there's the aforementioned complicated stuff to protect variables, but in a hypothetical old-fashioned BIOS, with standardized CMOS would just be free reign).
XML is like violence. If it doesn't solve the problem, use more.
Yes, that's proper practice. The problem is the punishment for bad practice has not historically included making the hardware inoperable without the intervention of the hardware supplier, who may deem such damage out of warranty.
XML is like violence. If it doesn't solve the problem, use more.
systemd did not do that. The implementations of UEFI that fail to protect themselves given the available mechanisms (yes, UEFI design anticipated just this sort of BS and added yet more complexity to provide for protection), the efivars interface design, the convention of mounting efivars all the time and r/w did that. systemd was following an existing precedent when they did that.
I don't like systemd, not a huge fan of UEFI, but I want to be crystal clear on the specific culprits and how it came to pass.
XML is like violence. If it doesn't solve the problem, use more.
That would make sense, but that's not the convention. I still think it would be more resilient for the kernel implementation of that pseudo-filesystem to *not* treat unlink so gravely, and provide an alternative interface.
Of course they would be right in calling out the firmware implementations for buggy behavior, but it doesn't seem like a terrible compromise to do that to mitigate risk a little.
XML is like violence. If it doesn't solve the problem, use more.
But this is really an EFI bug as others have said. Deleting those variables should regenerate with default values, not brick the motherboard.
+1 to you for circling back once you got that it bricks the system (and not just the install).
That is true. The problem is whether you hold out for the ideal or mitigate the risk of the reality. Of course, if this behavior persists and enough a stink raised, then system vendors might pay attention and test this as a matter of course. Now this won't help if say MSI doesn't care about Linux directly, but MSI probably uses AMI for their firmware, and at least *one* AMI client would hopefully propogate among the vendors.
XML is like violence. If it doesn't solve the problem, use more.
Next up, instead of encrypting your files, they'll just demand a bitcoin or permanently ruin your hardware...
Peter predicted that you would "deliberately forget" creation 2000 years ago...
Now this won't help if say MSI doesn't care about Linux directly
This isn't Linux-only. It's just easier to exploit. All you need is root/admin and direct hardware access and you can overwrite EFI in-OS.
Yes, though that ventures into a vulnerability (requires pretty explicit intent) and away from accidental mishap. So in theory should be considered very grave, but in practice the system vendors are even more lax about security issues than things like this.
XML is like violence. If it doesn't solve the problem, use more.
If you can brick your motherboard from userland, then so can malware.
Isn't this the kind of thing that the immutable attribute was designed for?
What is this newspeak "network stack" that you are referring to?
Last I checked, the "network stack" consists of things like TCP, IP, the physical layer, and other such mumbo-jumbo that is entirely done in the kernel and has fuck-all to do with userland.
Kid-proof tablet..
They call it dependency hell for a reason.
or DLL hell.
That's only fixable if we abandon the .dll or .so or whatever and have everything statically linked for every program.
Not gonna happen.
--
BMO
This is a massive security problem, someone could run this on 10,000 servers in parallel all at once and the business would be down for months replacing all the motherboards. Figure $500 and 1 hour per motherboard replacement and you are looking at 10,000 man hours and $5 million dollars in hardware damages alone.
The glob expansion won't do this if you start with "*" so it shouldn't search hidden files or directories.
"...Windows and other operating systems are also prone to this issue when using UEFI"
Well, no. They have the same underlying potential problem, yes... but Windows isn't susceptible to the rm -rf / since it doesn't, by default, have the rm command. These two aren't quite the same thing. The summary makes it sound like there's parity between Linux and Windows but that's not accurate. It takes about 20 lines of code (as per the article) to do the same thing on Windows. So yeah, it's a legitimate UNDERLYING problem, but let's not make it sound like it's the same situation on both platforms 'cause it's not really.
If a pion (n-) collides with a proton in the woods & noone is there to hear it, does lamdba decay into the source pa
Not only did it erase the firmware on my motherboard, it also deleted all of my files!
The code is not overwritten, but the code is not expecting *all* variable store data to be wiped, and may go down impossible paths.
If this becomes a standard test case, then you'll see firmware get more resilient to this over time.
Bricking a motherboard due to a bad firmware flash has been a serious concern for a long time (due to power-cut, or a bad floppy, or whatever). Support for any sort of backup firmware has always been sporadic. So I won't hold my breath.
Maybe someone should petition the sysfs guys to have a "00erasable" file as the first dirent in the UEFI space: the variables can only be removed if that file exists. Hopefully "rm *" will remove that file first, making the rest unerasable.
Or that, given the desire to boot into EFI firmware setup, a tool other than init wouldn't have the same problem that systemd does and wouldn't require the same writable filesystem to complete its task? Is your argument that such tools shouldn't exist? Because you didn't make any claims about how this is a problem because the two tools you would have need with sysvinit are now a single tool.
No, of course a tool like that would have a reason to exist, just like there are OS tools *now* that can flash firmware, reset BIOS variables, or whatnot. (Whether it's secure to have host-OS level access to those types of features is a different, albeit related question, of course...)
The problem is in what you've posted:
a tool other than init
If there are OS tools (like update_firmware from Dell's OMSA toolkit) requiring more access, then let them handle whatever they need to handle. And if they break, or do something stupid like leave something in read/write mode on the filesystem that can cause you to accidentally accidentally brick your server, then we get to blame them.
We don't want or need systemd to be involved in this, and we really don't want or need the systemd developers involved in this. No one died and made them benevolent dictators over the Linux userspace.
Hire a Linux system administrator, systems engineer,
First to actually type "rm -rf /"?
The last two motherboards I've bought boasted twin BIOS chips, such that if the active BIOS was corrupted a quick jumper connection would copy the read-only contents of the backup chip to the active chip, providing an easy out from a possibly bricked computer. Sounds to me like the affected motherboards didn't offer a similar feature for EFI, and were very cavalier about how they stored their system-critical data, so we should file this bug under "lazy/negligent mobo manufacturer".
That said, the kernel should be a bit more careful when applying "rm -rf" to EFI vars. When I decide to send my current setup to oblivion, I'd prefer it not take my hardware along for the ride.
Good excuse to get control over your own hardware. Bring back BIOS, /init and /var/log/messages. Systemd and UEFI can stay - just so long as they add 'emulate old ways' settings :-)
There is no need to reset the boot loader.
Most consumer machines do not even come with a replaceable operating system.
If the system gets hosed or riddled with viruses you just buy a new one. Does not happen very often. People accept that.
You hark back to days when you could have some understanding and control over your machine. Those days are long gone. Think about how a teenager interacts with a computer. That is the future.
That's probably just because you didn't boot in UEFI mode.
you need for the BIOS to be a read-only thing that can only be written from another computer. Yes, it can be rather inconvenient to have to have a removable BIOS stick, but it would be simple to recover from this by just removing the stick and re-writing it on another machine. http://www.pcworld.com/article... Having a read-only BIOS is great against hacking also. It also makes bios upgrades safer. You just have two sticks and always keep your old one as a backup.
Isn't "not running systemd" a good solution?
No, because it is a UEFI problem that can be invoked in Windows also. And last time I checked, Windows doesn't use systemd.
IOW, you could have a nationwide pogrom, summarily shoot the developers and proponents of systemd, make the use of systemd a capital crime, and you'd still have the problem because it is a UEFI problem.
Thank you systemd haters, who have not taken the place of microsoft shills in modding anything they disagree with as a troll. tl;dr systemd haters = microsoft shills, only unpaid.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
UEFI is the problem. Whatever 'enhancements' it brings belong as OS services.
I actually tried this with rm -rf -i /first/*.* but it didn't work. Maybe they fixed it?
Linux package managers are well overdue for redesign.
Perhaps so, but there's nothing on any other mainstream operating system that can compare in terms of software management.
And no, the OSX and Windows App Stores don't come remotely close.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
UEFI is accessible for change. Note the standard doesn't demand that 'getting bricked' be possible, it's the firmware developer implementations that have issues.
Right now the efi variables are normal files: $ ls /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c -l
-rw-r--r-- 1 root root 57 Jan 22 09:58 /sys/firmware/efi/efivars/Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
Thanks, I've not paid enough attention to this, I'm glad it didn't catch me.
So my proposal would be either to make each something like a character device, with special ioctl for 'deletion', or a normal file, except ignore 'unlink()' and provide a separate character device with ioctl to remove the variables, or some 'echo delete Boot000 > whatever' type interface. The latter is probably the best all things considered.
It seems reasonable, especially as it would offer a degree of protection against shitty UEFI implementations.
The whole acess to the variables space is already an abstraction, so efivars can do whatever they want (though would break downstream utilit(ies) expecting to be able to unlink, but I think that's worth the work. A utility can be backward compatible by checking for existence of new interface, and falling back to unlink should that new remove interface be missing.
Indeed, breaking a few utilities is a small price to pay so you can't brick a motherboard. Software can change.
My ism, it's full of beliefs.
Systemd is doing nothing here. The problem is not the kernel, it's not systemd mounting read/write, it's not even that you can write a specific program to write / delete these specific variables. It's not a linux problem. It's not even a UEFI problem.
It a specific coding problem from a specific case where the coder of a specific implementation of UEFI exposed variables to the system in ways designed to be written but didn't write a contingency to it being written incorrectly or deleted. It's firmware coding 101 and the person responsible should be castrated and banished to a userspace never to work on something as critically important as a bootloader again.
While you're blaming LP you can also blame my cat, she's meowing right now and I'm sure it's just as much her fault as LP's that a UEFI system is now borked by running a privileged command from an elevated position assisted by a kernel module specifically designed to all it to happen on a system designed (poorly) to have this changeable in the first place.
> No, he's not an idiot. He's a normal person. Normal people click uninstall and expect their game to be uninstalled, not their OS's GUI
No he's not an idiot, a fucking liar is what he is. There is no way that in any package management system XFCE would have a dependency on a Sudoku app, if anything the dependency would be the other way around. So no, removing Sudoku would never result in XFCE being deleted. Not even Ubuntu would be that stupid.
Actually, it could. Imagine you have a virtual package, say xfce-environment, which depends on sudoku and everything else XFCE. This package is the only package that is explicitly installed, and through it you got your DE. The system is configured to automatically remove packages that are not explicitly requested (mine works that way - when I remove a package, any package that is installed solely because it's a dependency of that package is also removed). So, luser uninstalls sudoku, which forces removal of virtual packagee xfce-environment (since this virtual package has a dependency on everything, including sudoku), now every single other package that xfce-environment depended on, which has no other reasons to exist on the system, will also be uninstalled. I can see this happening, and have seen similar situations myself.
Now, I don't think the system is in the wrong here - the user should probably have paid a bit more attention, but I do not think his story is necessarily false.
May we live long and die out
Don't forget the scripts that fail to work with path names that contain blanks! This is quite common on OS X when the hard drive is usually named "Macintosh HD". (I renamed mine to "Macintosh-HD" just in case.)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Or it may simply be unable to access things like USB and SATA controllers when their configuration is erased. If it was unable to access keyboard and display, you wouldn't be able to use a "reset to defaults" option, if there even was one.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Clearly you don't know much about *NIX if you think that a file system is the same as a hard drive, and that every directory entry in the file system corresponds to a collection of sectors on a hard drive. Besides, this isn't even about deleting everything from the / root, you can also start at the root of the fake file system that represents the EFI variables, or do a recursive delete that goes backwards like "rm -rf .*".
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
You're surprised that crappy programmers that don't even think about such possibilities are employed to do BIOS work for motherboard companies?
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Are people seriously advocating for systemd to be a babysitter for the root user? I would definitely be more upset if systemd posed restrictions upon what I was allowed to do (as root). But, sure, I understand the problem (which Etcetera seems to be the only one to touch upon) that systemd makes it harder to strengthen the security by generally limiting the possibilities to customize your system.
People who come from a DOS/Windows background also seem to think that "rm -rf /" should be expected to work like "format c:". But the root is not just the (first) harddrive and as a user of Unix (where "everything is a file") I would rather translate it to "delete everything there is to delete, yes really". I wouldn't find it strange if stuff on the network got deleted too, not just regular files but printer queues and whatever. Not to mention all sorts of flash memory of any sort of attached device.
If anyone is to blame here it's the BIOS developer I think. A more robust implementation would have some fallback code in ROM that lets you at least install a new flash image. But while PCs have generally been quite robust (until now), where have been other more easily bricked systems. Sometimes you can remove the flash IC and rewrite it. Sometimes you just have to toss the hardware. It's annoying but it doesn't make me blame the software for not preventing me from doing the mistakes I did (which wasn't simply running "rm -rf /" by the way).
I'm guessing it refers to NetworkManager, the GUI tool for finding available networks and configuring interfaces to connect to them. WLAN in particular is a lot more complex than ye olde ifup eth0.
I prefer rm -fr / because then in my mind I can blame it on the French.
.. of course it would be quite easy to design an in-circuit programmer, but generally they were read-only with the exception of a UV light or being left on a window sill ..
There is nothing wrong with having UEFI variables available for read/write. If you're going to screw with them, you have to expect to have to do something special to boot up again if you mess up. What is wrong is having it possible to change UEFI variables to the extent that it's not possible to boot. That's not a systemd problem. Any motherboard that can be effectively destroyed by running software on it has big problems.
If I can remove or reinstall disk drives or RAM or whatever, use a DVD or USB stick or something to boot to the point where I can reinstall the OS, reload all the software I'd installed, and connect to Dropbox for my personal files, it's not actually bricked. These motherboards have a user-accessible brick mode.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I had an XP laptop once that apparently couldn't take a certain Windows update. After that one, it would just stop and hang at random intervals, requiring a restart. I was going to use System Restore to figure out which update, but when I started the bisection process it stopped and hung in the middle of replacing a file needed for the user interface (don't remember which one), so I had to boot from floppy, figure out which file was missing, download a copy somewhere, and replace it before I could boot Windows again. At that point, I just System Restored it back to when I got it, and decided never to buy a Compaq laptop ever again. That particular decision has become a bit easier to adhere to, to be honest.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
The comments here are why a lot of level-headed people have a prejudice that anti-Linux comments are likely from haters. This is not a Linux problem. The fact that this report shows how the problem can come up while running Linux doesn't mean it can't or won't happen on any other OS.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
It's a systemd problem because of the defaults that it sets, not because of the buggy implementation.
Y'all are missing the point. There's no good reason for the init system to try to rewrite EFI variables, hence no reason for the init system to force mount efivarsfs into r/w mode. It's an unsafe default and there's absolutely NO reason for an init system to have a care (or a say) about the local policy one might adopt or prefer in dealing with that issue.
The systemd developers have decided to adopt the kitchen sink approach and consume other utilities and processes within the boot system. With the default action here present at https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L110 systemd is now involved in complaints about exposing an unsafe mount point by default, and flippantly closing it WONTFIX.
Hire a Linux system administrator, systems engineer,
To preserve this capability, Windows 10 does its best to not give the user a choice about accepting updates.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Using your reasoning, all ACs are idiots who don't know what they're talking about.
After all, you're describing one specific event, which probably didn't happen quite the way you tell it (whenever I get sufficient information about such a story, there's almost always important things left out), and concluding from that that Linux is screwed up.
To quote a friend, "Everyone generalizes from one example. I know I do." However, this friend actually knows it's a joke.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
You're honestly trying to tell me that RedHat can't change the systemd configuration (or code) to match their desires?
Won't, sadly, and for the record... https://bugzilla.redhat.com/show_bug.cgi?id=1304078:
Fedora's policy of trying to stay close to upstream is about 15% to blame, and the rest is simply what distros will end up doing: taking the easy path. This is why centralization is a bad thing... It's going from the Bazaar back to the Cathedral in terms of lack of meaningful ability to influence. The "systemd cabal" is exactly that.
Hire a Linux system administrator, systems engineer,
I'm surprised that you've included a dot in that - it'd be more effective to run rm -rf /first/*
You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
And nearly the last comment:
Slashdot, get your peanuts here!
Watch this Heartland Institute video
Yes, yes it would've happened without systemd.
Particularly as it also happens on Windows.
The UEFI implementation is fundamentally broken. No piece of userland software is going to fix it in an acceptable way.
And no, mounting ro is not a fix. It's a cheap hack that doesn't do anything to alleviate the situation. It protects people from their own stupidity while breaking other applications. And black hats will still be able to remount those variables before bricking your hardware.
In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough? And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
In other words, it's a systemd problem because it doesn't hide the self-destruct switch enough?
Yes. There's a reason Big Red Buttons in datacenters usually have a protective cover on them.
And that the fact that the motherboard comes with a convenient software self-destruct switch isn't really a problem? Is it a problem with the vendor for not selling these mobos only to supervillains?
I've absolutely never said that the motherboard issue isn't a problem. In fact, I'm not sure I've seen *anyone* say that *anywhere* online in this entire debate... What IS a problem is that a random github project has control over the types of things that used to be decided at a much more distributed level. Complaints to distros are now sent upstream, where the self-described cabal decides what does and doesn't fit into their agenda for the Linux userspace.
No one asked for this.
Hire a Linux system administrator, systems engineer,