> I actually expected Windows’ Syscall translation layer for Linux to block any such clearly destructive actions.
Well, I bet, if it blocked these actions, there would have been another blog complaining how the Linux subsystem is just a toy, goes against the Unix tradition of "can shoot yourself in the foot if you really want" etc etc.
And I'd definitely much rather be able to do dangerous things if I want to, than be told that I need to be protected from them. I do appreciate that rm -rf requires "--no-preserve-root" for that extra level of certainty, but the author of the OP should not be surprised at what happened.
In particular, the underlying translation layer can't prevent this without completely breaking the ability to operate on Windows files from the Linux compatibility subsystem. "rm -rf" just recurses through the directory tree and calls unlink() on every file and rmdir() on every directory. Making rmdir() refuse to work on /mnt/c wouldn't help; by the time that syscall occurs, rm has removed every other file and directory. "find / -delete" would have the same effect.
And if you prevent unlink() or rmdir() from working on files within /mnt/c or other Windows drives, you would not only break the ability to do normal file management with rm or other Linux tools; you'd also break every application that creates and removes temporary files, or otherwise manages files programmatically. You couldn't, for instance, use "git checkout", because that unlinks files and rmdirs directories present in the current HEAD but not present in the new target to check out.
rm (without --no-preserve-root) specifically checks for an attempt to remove / before it starts recursing. You could potentially improve rm to preserve a few more directories by default; some tools exist to do exactly that, such as safe-rm.
rm's default --preserve-root behavior mostly exists to help catch cases like "rm -rf $VAR/$VAR2", which with VAR and VAR2 unset would turn into "rm -rf /".
(Personally, I'd like to have rm add and default to a --preserve-home option too, to catch things like "rm -rf $HOME/$VAR" or "rm -rf ~/$VAR" or "rm -rf ~ /foo".)
That's fine until 4chan starts distributing images telling people to run this cool command to speed up their computer or something stupid. Ala delete system 32. They will have to lock this down like they did with system 32. Users do need to be protected from their own stupidity.
Running a random shell command from the Internet without understanding it can do any number of terrible things; removing all your files and making your system unbootable is not the worst that could happen.
--no-preserve-root seems like a sufficient safeguard here.
I'm just making predictions. That this will become a malicious advice meme. That lots of people will lose all their files over it. And that microsoft will probably disable it.
This exact thing happened with system32. And deleting a system file somehow seems much more obviously dangerous than entering a command you don't understand. "rm" looks pretty harmless, and someone could come up with a backronym that even makes it seem sensible.
In fact I wonder if this is the reason pasting into console is disabled, or at least hard to figure out, on Windows.
Why do you think this is the reason system32 was protected? I think it was simply protected for the same reason the program files folder was, which is security. Not to prevent user mistakes.
Users do need to be protected from their own stupidity.
I think they definitely don't; instead, they need to learn from it. Mollycoddling them will only encourage such stupidity and help it proliferate. If taking a few seconds to search online for more information is beyond their ability, then they deserve everything that happens to them.
Look see my above comment. There's no need to downvote me, I'm just making a prediction based on a very similar situation that happened in the past exactly the way I describe.
Whether or not users "need" to be protected from stupidity is an opinion of course. But it's in Microsoft's interest to protect their users, and users want to be protected. So who is to say they are wrong to do so?
I find your assertion that the world would be a better place if more people made serious mistakes, really hard to believe. A 10 year old ruining his parents computer might teach him a lesson. But how much does he gain from that lesson, really? And at what cost? Would you personally help distribute malicious advice memes, if you really believe this is a good thing?
I think this is actually a good thing, Linux being a first class citizen in this environment and all. Linux is a different beast from Windows, and this being a developer tool, will not babysit the user as much.
So you run a destructive command and you are surprised it destroyed your system? The sub system is not an isolated vm so it does what it's supposed to do. I don't see a problem here you could achieve the same thing in regular windows command prompt or powershell.
Just to be clear, this calls the command "rd" (remove directory) with argument /s (recursively remove all subdirectories) and path \ (root of your drive).
Initially it looked to me like a switch called "crd" as argument to the "cmd" command. This would have fooled me into thinking it is harmless. I wouldn't have fallen for "format c:" but I might have fallen for this.
The space between "/c" and "rd" is apparently not necessary. I tested it and it really works.
Hm, does this mean it ignores win32 file locking? By that I mean files are locked against deletion while a handle to them is held open, unlike on posix systems where you can rm an open file and it just unlinks it from the filesystem without deleting the data (until the refcount goes to zero).
The level of damage described sounds like it does.
Do you really need the Linux subsystem to do mass deletions on Windows?
Googling around tells me that good old "deltree" no longer exists, but I would have assumed PowerShell would have some equivalent. If you do such a thing as administrator, won't you expect serious damage?
I thought perhaps the Linux layer lets you delete/unlink files that are in use, unlike Windows. But I also thought this was pretty baked into the kernel/VM paging system.
If the Linux layer allows deleting and replacing in-use files, that's pretty cool and a welcome feature.
If this is just a substitute for deltree I'm not sure I get the point.
Windows (at least NTFS) does allow you to delete files in use as long as it has been opened with a sharing mode of FILE_SHARE_DELETE. Unfortunately most regular programs don't do this.
An exception to this is memory mapped files as they are not allowed to be deleted that way. Executables are executed in Windows by memory-mapping them; so runnning programs are hard to delete.
According to the article, removing / didn't touch the stuff in /mnt/c. Therefore, I would assume (but obviously not test myself!) that this just stops as soon as it sees another mount point.
I just checked the `rm` source code for the GNU coreutils, and it actually checks for `/` by checking for identical device and inode numbers to `/`. I admittedly don't want to test if the feature works, but in theory if you remount `/` at a different location `rm` will still require the `--no-preserve-root` flag to delete it.
That said, the above only saves you if `/` and `/mnt/c` are the same device mounted at two different places - I haven't used the system to know.
If you assume a non-Administrator/non-UAC elevated user can't delete anything in c:\windows this does raise the question of why the Linux subsystem has so many privileges
I'm curious about this myself. I would have to be an elevated command prompt to do this natively in Windows. I would assume that, by default, the Linux subsystem runs non-Elevated. If this is not the case then the Linux subsystem is a bit of security risk in Windows.
"Trusted Installer" also protects other folders like "program files", all of a sudden dll injection / unescaped path vulnerabilities might become much more common if this is indeed an issue.
Nothing actually stopping you from deleting "explorer.exe" from gui/cmd but you have to do some steps in order to take ownership of those files even with admin rights, this includes interacting with the UAC functionality in windows.
Seems that the new linux subsystem bypasses that and unless the guy in the article has already disabled every security measure in windows this is a big deal.
And no I won't consider it a bug, I don't care what root should or should not be able to do the fact that a user can delete critical system files while the OS is running is bad design there is simply no scenario in which you would want or need to do it, not in Windows and not even in Linux.
In an interview with BSDNow[0], Bryan Cantrill had mentioned how at Sun, they'd discussed with the person in charge of POSIX compliance, and got a clearance to specifically check for this case and prevent it. This code is present in Illumos [1].
I'm very excited about the Subsystem for Linux. It will make Windows a great all-purpose development system. As it is, I have an easier time running must GNU/Linuxy stuff on cygwin than I do on Mac....
Exactly right: OpenCV is the worst. And lots of trouble with Python 2 and 3 things that "just work" on Windows. I guess people don't do a lot of "real development" on Macs -- around the world, Windows is still the standard.
The only thing I use regularly that works better on Mac is "Vagrant" 1.8. I have to stay on 1.7.4 on Windows. If you look at their issue tracker, it's clear nobody's caring too much about Windows over there. Of course, with the Subsystem For Linux, I can just run the Linux one on Windows!
I think this depends on what you consider “real development”. I always thought people don’t do any "real development" on non-unix systems. As far as anything Internet or modern goes, Windows is far, far from the standard. I guess that’s the point of this compatiblity layer, after all.
Well, I bet, if it blocked these actions, there would have been another blog complaining how the Linux subsystem is just a toy, goes against the Unix tradition of "can shoot yourself in the foot if you really want" etc etc.