Rm -rf / in Windows Subsystem for Linux reveals sharp set of teeth

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.

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.

But does the Linux subsystem actually understand that /mnt/c is the root of the drive, or can you omit the option?

This has been fixed in recent Windows insider builds.

You would have to be in an elevated command prompt and manually take ownership from "trusted installer" in order to do it.

"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.

That's in the 'rm' command; not in the syscall itself.

You have the same thing in other OSes, hence --no-preserve-root

libsdr (might have been librtlsdr) and opencv here. Complete and total nightmare to get either of those going.

Total cake on a windows system.

Anything that requires python libraries outside of the bog standard seems to be a 50/50 tossup on OS X.