SoylentNews is people
SoylentNews
If you're a Steam user — beware, even slight modifications of your system may result in the nuking of your home directory, and more!
Fortunately, as the entry point for the user is a shell script (bash, but that's another story), it's been quite easy to find the source of the problem, the lack of sanitising shell variables before passing them to potentially dangerous commands — in this case, “rm -rf "$STEAMROOT/"*'”. The commit that introduced the bug also seems to have contained a remarkably apt comment ``#Scary!'' (it's not clear that the repo being pointed to, and its commits, mirror exactly the same commits as Steam themselves would have added them.)
It seems that even on MS Windows, Steam gets a bit over-eager about deleting files it doesn't own.
As a software engineer, who's also been a package maintainer on huge projects with up to 70 engineers wanting to force patches into my tree, I've become hyper-attuned to the concept of asking "what could possibly go wrong" (and having a mindset like Bob the Bastard from the animated Dilbert series), and consequently for demanding small readable patches which do just one small thing that's trivial to review. Would the patch have passed review? How confident are you about the quality of the rest of the code if things like this can slip through?
(Score: 1) by WizardFusion on Friday January 16 2015, @02:04PM
This only happens when you uninstall Steam.
I can see the reasons behind cleaning up the application folder when it is being uninstalled, but more validation is required.
(Score: 2) by Marand on Saturday January 17 2015, @01:37AM
This only happens when you uninstall Steam.
Nope, it happens when the reset_steam function is called, which occurs in one of two cases. One is if you explicitly call --reset, the other is inside an if statement near the end of the script that appears to be part of a version check. Having your update checker potentially attempting rm -rf /* is pretty bad.
In either case, it calls reset_steam, which is supposed to move some files to a safe location, wipe the directory, restore the saved files, and start over. The problem is the script assumes that the variable gets set as expected, with no checks at all, and then runs risky, poorly-written commands based on that assumption. It looks like a lot could go wrong with the way they set this up, so it's a bit worse than "just don't uninstall/reinstall and you're safe".