Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by LaminatorX on Friday January 16 2015, @01:55PM   Printer-friendly
from the no-shortcuts dept.

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?

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by tynin on Friday January 16 2015, @02:52PM

    by tynin (2013) on Friday January 16 2015, @02:52PM (#135374) Journal

    We had something similarly bad occur at work. Without going into too many details, a platform developer decided that he didn't want to trust operations to make sure file ownerships were set correctly. So a chown -R was put in to "correctly" set the ownership on the instance directory. Unfortunately, some of our users have their instance directory set to /, which likely wasn't the best place for it, but in their defense it worked fine for years prior. So when we upgraded to this newer platform build, suddenly some servers failed in interesting ways, and continued to fail after a reboot. Turns out some system dirs aren't very happy having their ownership get changed to a non-privileged user.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2