17 ms·

steam. Ran steam. It deleted everything owned by user

603 points by stkhlm 12y ago

eastbayjake 12y ago
If you're curious about who the "Scary!" guy is, someone pointed to where the code was checked in: https://github.com/lrusak/steam_latest/commit/21cc14158c171f5912b04b83abf41205eb804b31 https://github.com/lrusak/steam_latest/commit/21cc14158c171f...
- rcxdude 12y ago
  That looks like an unofficial repo. I don't think the guy who committed that actually wrote it.
- wintersFright 12y ago
  some hilarious comments there now
Chris_Newton 12y ago
This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data without warning in such a sweeping way. I have often made this argument in the context of sandboxing communications software like browsers and e-mail clients, where it is relatively unusual to need access to local files except for their own data. In that context, restricting access to other parts of the filesystem unless explicitly approved would be a useful defence against security vulnerabilities being exploited by data from remote sources. It’s hard to encrypt someone’s data and hold it for ransom or to upload sensitive documents if your malware-infected process gets killed the moment it starts poking around where it has no business being. More generally, I see no reason that we shouldn’t limit applications’ access to any system by default, following the basic security principle of least privilege. We have useful access control lists based on concepts of ownership by users and groups and reserving different parts of the filesystem for different people. Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?
- andrewfong 12y ago
  Isn't this the basic idea behind the sandbox in OS X? I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address. First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broader access. Second, as a corollary of the first, that means you're going to have a lot of apps that legitimately need to ask users to approve broader access. And as the number of apps asking for approval goes up, the more likely users are to simply ignore the warning and approve all. This is especially problematic since we can assume the average user is a good judge of which apps need which access. Edit: One way of reducing user acceptance fatigue might to introduce greater granularity into the requested permissions and then tier the permissions requested -- e.g. commonly asked vs. uncommon. E.g. an app may legitimately need permission to write to any file in your home directory, but it's highly unlikely they'll need permission to write to more than X number of files per second. Or at least they shouldn't be able to do so without the OS throwing up lots of warnings outside of the app.
  - gizmo686 12y ago
    It helps if you assume good faith of the application developer. Part of developing an application should be defining what permissions you need at install time. This won't help against legitimate malice, but it would defend against this type of mistake, and (if it is configured such that the app cannot change its own permissions) will also mitigate any exploit of the app.
  - ejdyksen 12y ago
    Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1]. For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed container. [1] https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW17 https://developer.apple.com/library/mac/documentation/Securi...
kazinator 12y ago
rm -rf "$STEAMROOT/"* This is why serious bash scripts use set -u # trap uses of unset variables Won't help with deliberately blank ones, of course. Scripting languages in which all variables are defined if you so much as breathe their names are such a scourge ... I did this once in a build script. It wiped out all of /usr/lib. Of course, it was running as root! That machine was saved by a sysadmin who had a similar installation; we copied some libs from his machine and everything was cool.
- falcolas 12y ago
  rm --preserve-root -rf "$STEAMROOT/"* would have worked too.
  - firethief 12y ago
    Really? Have you tried it? If your shell expands globs and you have any directories below / (both very common conditions), rm will not receive any arguments that are the root directory, and your --preserve-root will not alter its behavior. --preserve-root would help if the author of this particular nugget hadn't made the additional mistake of inserting a needless /*, but with that there the root directory would never be an argument to the rm.
- jzwinck 12y ago
  While you're at it: set -e # exit on unchecked failure That way you don't trudge forward through an untested code path after a failure, you stop there and then.
  - oblio 12y ago
    I use this holy trinity in most of my scripts: set -o nounset # set -u set -o errexit # set -e set -o pipefail # I'm not sure this has a short form. I use the long forms for the option names because they're self documenting. If anyone has more suggestions, I'm all ears.
    - drothlis 12y ago
stevewilhelm 12y ago
Many of the comments mentioned this should have been caught in the code review. I suspect they don't perform code reviews. Makes me wonder, is there a tool, system, service for auditing how many 'pair of eyes' have reviewed a given line of code. This would be hard to determine, but could be useful. I am envisioning a heatmap bar or overlay that indicates the number of reviews a line of code has received.
- comboy 12y ago
  I would use that. For unpopular open source projects. Let me review and comment other people code, make them review mine. Some rating is probably needed. Very nice idea.
- noarchy 12y ago
  It is trivial to find systems where you can assign specific people to review code, of course. Plenty exist. But to guarantee that they truly read a line of code, rather than skimmed/scrolled through it? Even if they paused their scrolling on that line, it doesn't mean that they really read it, or did so with proper understanding of what it was doing. Short of placing an actual comment or question for that line (demonstrating some real interaction), it doesn't seem like an easy problem to tackle.
  - skeoh 12y ago
    I think there's merit in the idea -- not tracking what a code reviewer reads but more of tracking how many times each line of code has been _included_ in a review, by being modified or maybe within so many lines of a change (like how diffs show X lines of surrounding context). The idea would be that code changes _near_ a buggy line would be more likely to draw attention to that bug and perhaps lines with less attention would be more likely to facilitate hidden bugs.
    - jacalata 12y ago
      I suspect it would work out the other way round - code in a frequently modified section would be more likely to hold bugs because the requirements/understanding of that code is changing more frequently.
izietto 12y ago
IT reminds me the Bumblebee Project bug: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue... Spoiler: due to a forgotten space the entire /usr folder was deleted
chj 12y ago
This could be quick hack, maybe the dev just forgot to put it on the issue list.
preconsider 12y ago
To those name-calling the author of the script: The product/update is hyped and the release date is set in stone. Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals. A last-minute showstopper bug comes in, caused by file leaks. Everyone is scrambling, and the file belongs to you so its on you to fix it alone. There is no time for code review, and delaying isn't an option (so says management). "I'm afraid if we keep seeing these delays in your components, we might have to consider rehiring your position". The rm rf works -- it's a little bit scary, but it works. You write a test case, and everything passes. Still, you add the "scary" line for good measure. You have two more bugs for fix today and you'll be lucky if you're home by midnight and see your wife or kids. You've been stuck in the office and haven't seen them in days. Are you an "idiot", "talentless" engineer that "deserves to have his software engineering license permanently revoked"? How do you know this wasn't the genesis of this line of code?
- click170 12y ago
  This. This is the reality of corporate development. I think we should be demanding more before buying software from vendors, especially when you can't just whip out the source code to audit or fix yourself. Suff like this doesn't have to happen, but we let it.
- cechner 12y ago
  but the same wouldnt be acceptable in other lines of work right? Try a civil engineer or surgeon... what would you expect someone to do in similar situations? Probably escalate the issue and perhaps delay the release. Pushing in shitty broken means you're not doing your job. If your company forces you to do this then they are not doing their job.
- wpietri 12y ago
  Yes, that person is still an unprofessional idiot. If a doctor accidentally removes the wrong organ because administrators have overscheduled him, "whoopsie, not my fault" is not the appropriate answer. The same applies to engineers working on bridges. Professionals take responsibility for their working conditions. There is an enormous shortage of programmers right now. Anybody shipping stuff that is bad or dangerous is choosing that. If we drop our professional standards the moment a boss makes a sadface, then we're not professionals.
douche 12y ago
Why are we still running bash scripts? The only thing worse might be DOS batch files. It's not like python isn't available on every major linux distro. It's a little harder to ensure it's on windows, but when Steam is installing every point release of the Visual C++ runtime that has ever existed on my system, why not bundle python in there too?
- deleted 12y ago
  [deleted]
- woodman 12y ago
  > Why are we still running bash scripts? Because admins gotta admin. Also, adding python to a software suite just to work on the file system... gross.
- mst 12y ago
  And even if it isn't, modern perl would do as well as python for this case, with no language wars required.
  - douche 12y ago
    Exactly. There are better options, that have more sane string and path handling. Much as I grumble about using Powershell on Windows, at least you've got the .Net framework underneath you that you can drop into relatively easily
bcantrill 12y ago
Wow, an awful bug -- and brings back memories of a very similar bug that we had back in the late 1990s at Sun. Operating system patches on Solaris were added with a program called patchadd(1M), which, as it turns out, was actually a horrific shell script, and had a line that did this: rm -rf $1/$2 Under certain kinds of bad input, the function that had this line would be called without any arguments -- and this (like the bug here) would become into "rm -rf /". This horrible, horrible bug lay in wait, until one day the compiler group shipped a patch that looked, felt and smelled like an OS patch that one would add with patchadd(1M) -- but it was in fact a tarball that needed to be applied with tar(1). One of the first systems administrators to download this patch (naturally) tried to apply it with patchadd(1M), and fell into the error case above. She had applied this on her local workstation before attempting it anywhere else, and as her machine started to rumble, she naturally assumed that the patch was busily being applied, and stepped away for a cup of coffee. You can only imagine the feeling that she must have had when she returned to a system to find that patchadd(1M) was complaining about not being able to remove certain device nodes and, most peculiarly, not being able to remove remote filesystems (!). Yes, "rm -rf /" will destroy your entire network if you let it -- and you can only imagine the administrator's reaction as it dawned on her that this was blowing away her system. Back at Sun, we were obviously horrified to hear of this. We fixed the bug (though the engineer who introduced it did try for about a second and a half to defend it), and then had a broader discussion: why the hell does the system allow itself to be blown away with "rm -rf /"?! A self-destruct button really doesn't make sense, especially when it could so easily be mistakenly pressed by a shell script. So we resolved to make "rm -rf /" error out, and we were getting the wheels turning on this when our representative to the standards bodies got wind of our effort. He pointed out that we couldn't simply do this -- that if the user asked for a recursive remove of the root directory, that's what we had to do. It's a tribute to the engineer who picked this up that he refused to be daunted by this, and he read the standard very closely. The standard says a couple of key things: 1. If an rm(1) implies the removal of multiple files, the order of that removal is undefined 2. If an rm(1) implies the removal of multiple files, and a removal of one of those files fails, the behavior with respect to the other files is undefined (that is, maybe they're removed, maybe they're not -- the whole command fails. 3. It's always illegal to remove the current directory. You might be able to imagine where we went with this: because "rm -rf /" always implies a removal of the current directory which will always fail, we "defined" our implementation to attempt this removal "first" and fail the entire operation if (when) it "failed". The net of it is that "rm -rf /" fails explicitly on Solaris and its modern derivatives (illumos, SmartOS, OmniOS, etc.): # uname -a SunOS headnode 5.11 joyent_20150113T200918Z i86pc i386 i86pc # rm -rf / rm of / is not allowed May every OS everywhere make the same improvement!
Alupis 12y ago
I've done something like this before, with my own build scripts. Except I was running as root (a requirement for some parts of the build). Part of the scripts installed a bunch of files into what was supposed to be a fakeroot, however I did not have bash's 'set -u' configured and an incorrectly spelled path variable was null, meaning something like: "${FAKEROOT}/etc" was translated into "/etc". Before I realized it, it had clobbered most of my /etc directory. When the build failed, I was puzzled. I only noticed there was an issue when I opened a new shell and instead of seeing "myuser@host ~]#" I got "noname@unknown ~]#". Uh oh... Needless to say I know do my development of those scripts from within a VM.
orblivion 12y ago
Thanks for reminding me to unmount my backup drive.
mofle 12y ago
I've written a short guide on how you should safeguard `rm`: https://github.com/sindresorhus/guides/blob/master/how-not-to-rm-yourself.md#safeguard-rm https://github.com/sindresorhus/guides/blob/master/how-not-t...
orbitingpluto 12y ago
Horrible life lesson. Saved by my own laziness.
mtsmithhn 12y ago
The sad sad part of all this is that Half-life 1 had a similar bug in their windows installer and would wipe your program files if not careful http://arstechnica.com/civis/viewtopic.php?t=479484 http://arstechnica.com/civis/viewtopic.php?t=479484
- gcp 12y ago
  One update to Eve Online had a broken script that removed "boot.ini" in some circumstances. Customers were not amused.
- DCoder 12y ago
  Myth II had a similar bug, too: http://minimaxir.com/2013/06/working-as-intended/ http://minimaxir.com/2013/06/working-as-intended/
leni536 12y ago
Well I'm on the guy's side but this worth noting: Including my 3tb external drive I back everything up to that was mounted under /media. Well maybe it was just unfortunate and the drive just happened to be mounted or the "backup" is always online. If it is the latter it is a really bad idea. If your computer is compromised you risk all of your backup. A proper backup should protect your data from these occasions.
im3w1l 12y ago
Just wanted to remind everyone that deleted files can be recovered until their space is reclaimed for something else. So if you notice something like this happening, shut down computer asap, so they can't be overwritten. Plug drive into another computer but do not mount it. Instead run some file recovery program on it. For an SSD it becomes murkier though, what with their trimming and automatic garbage collection.
- nodata 12y ago
  Yeah if you have time to manually guess the filenames on half a million files. Great.
  - im3w1l 12y ago
    $ extundelete /dev/sda{n} --restore-all
deleted 12y ago
[deleted]
blueskin_ 12y ago
This is an amateur mistake. Makes me wonder what horrors lurk inside Steam itself...
tomaskafka 12y ago
Another beautiful example of developer/user priority inversion. All system architects ever: 1) System data are sacred, we must build a secure system of privileges disallowing anyone to touch them 2) User data are completely disposable, any user's program can delete anything. All users ever: 1) What? I can reinstall that thing in 20 minutes, there's like 100 million copies worldwide of these files. 2) These are my unique and precious files worth years of work, no one can touch them without my permission!
deleted 12y ago
[deleted]
keruspe 12y ago
Pretty sure shellcheck ( http://www.shellcheck.net/ http://www.shellcheck.net/ ) has a lot to say about this faulty script...
deeviant 12y ago
Reminds me of a bug with the Myth II uninstaller immortalized by the following Penny Arcade cartoon: http://www.penny-arcade.com/comic/1999/01/06 http://www.penny-arcade.com/comic/1999/01/06 Basically, they called delete tree. If the user installed or moved the game to a different location, say, the root, it would delete tree away somebody's whole computer. Fun times.
nodesocket 12y ago
What is this magic doing? $(cd "${0%/*}")
- endgame 12y ago
  It's a bashism. Open up "man bash" and search for "Remove matching suffix pattern".
  - clebio 12y ago
    which, regrettably, is not something you can do with `man` if you find `${0%/*}` in a script you're reading that someone else wrote.
    - endgame 12y ago
      No, but you can find it by searching for "%", because that's exactly what I did.
- DangerousPie 12y ago
  $0 is the path of the script. ${0%/* } takes $0, deletes the smallest substring matching /* from the right (the filename) and returns the rest, which would be the directory of the script. So this changes the directory to the directory the script is located in.
  - rjgray 12y ago
    Is there any good reason to use this approach over the more readable 'dirname $0'? Not that it would have made any difference to the bug in question of course.
  - barrkel 12y ago
    $0 is not the path of the script. $0 is the path passed to the shell used to execute the script. If run via the #! line, it will contain a path of some kind. But if it's passed directly using "bash myscript.sh", then it won't. And yes, dirname is a way out of this. I'd do this: "$(cd "$(dirname "$0")"; pwd)" if I wanted the path to the script. I would also sanity-check the path by testing for the existence of some files or directories that are expected to exist under it, before trying to delete it all.
akamaka 12y ago
Here's the offending shell script code: # figure out the absolute path to the script being run a bit # non-obvious, the ${0%/*} pulls the path out of $0, cd's into the # specified directory, then uses $PWD to figure out where that # directory lives - and all this in a subshell, so we don't affect # $PWD STEAMROOT="$(cd "${0%/*}" && echo $PWD)" [...] # Scary! rm -rf "$STEAMROOT/"* The programmer knew the danger and did nothing but write the "Scary!" comment. Sad, but all-too-familiar.
- ghuntley 12y ago
  Offending commit @ https://github.com/lrusak/steam_latest/commit/21cc14158c171f5912b04b83abf41205eb804b31#diff-9f48ba7f3b9e90e945e5b1fe7654c74cR358 https://github.com/lrusak/steam_latest/commit/21cc14158c171f...
  - zamalek 12y ago
    The reaction images/memes are priceless.
  - gcp 12y ago
    Actually, that repo is just a user who extracted the Steam .debs into a github repo, the comments are completely misdirected.
- Qantourisc 12y ago
  Whenever I write something scary like that, I usually wrap it in a function, double checking if it's really the folder you wish to delete ... Often even adding a user-verification if possible.
- iamtew 12y ago
  Since the script is written in bash they could also have used $BASH_SOURCE, which will always point to the correct path of the script being executed, so you can do something like this: SCRIPT="$BASH_SOURCE" SCRIPT_DIR="$(dirname "$BASH_SOURCE")"
- deeviant 12y ago
colanderman 12y ago
# Scary! rm -rf "$STEAMROOT/"* Anybody who writes a line like this deserves their software engineer license revoked. This isn't the first time I've seen shit like this (I've seen it in scripts expected to be run as root, no less); it makes my blood boil. Seriously. "xargs rm -df -- < MANIFEST" is not that hard. EDIT: I shouldn't be so harsh, if it weren't for the comment admitting knowing how poor an idea this line is.
- Guthur 12y ago
  Is there proof that the comment was committed with the line of code? Of course once it was a identified a concerted effort could have been made to rectify the situation. Sometimes a problem is identified working on some unrelated aspect of the software and the developer does not have time or scope to change the offending piece of code but wants to place a red flag. Of course this example does not appear to be systematic approach to marking "fixme", unless of course their fixme tag is actually #scary. Edit: Of course one would hope they have raised a rather high priority work item for this.
  - deleted 12y ago
    [deleted]
- irishcoffee 12y ago
  The programmer committed a cardinal sin to be sure. But, so did everyone on the code review that let it slide.
  - noarchy 12y ago
    Do we know if they do code review? Are pull requests blindly accepted?
    - irishcoffee 12y ago
      If valve doesn't do code reviews, and if pull requests are actually blindly accepted (is that actually a thing? Do people ever actually blindly accept pull requests?) I don't think I have the wherewithal to give a useful response.
fsaintjacques 12y ago
Note to all, prepend all your bash script with "set -o errexit -o nounset -o pipefail" It'll save you headaches.
- shawkinaw 12y ago
  Yep, my thought exactly. My standard bash header is #!/bin/bash set -eu IFS=$'\n\t' (Wish there was a shorthand version of pipefail, then I'd always use that too.)
  - LeoPanthera 12y ago
    You can save a line by doing #!/bin/bash -eu
    - krotton 12y ago
      Which is no equivalent if the script is executed using "bash script.sh" ;).
- mod 12y ago
  Can you at least explain what this is doing, outside of saving me headaches?
  - barsonme 12y ago
    set -o errexit (set -e): exit script when command fails set -o nounset (set -u): exit script when it tries to use undeclared variables set -o pipefail: returns error from pipe `|` if any of the commands in the pipe fail (normally just returns an error if the last fails)
  - redsymbol 12y ago
    http://redsymbol.net/articles/unofficial-bash-strict-mode/ http://redsymbol.net/articles/unofficial-bash-strict-mode/
  - Anderkent 12y ago
jtokoph 12y ago
The biggest lesson here is that backing up your files is extremely important. Both local backups and remote backups. I like the 3-2-1 rule: At least three copies, In two different formats, with one of those copies off-site. Software is written by humans who will undoubtably miss a corner case and not think of every possible environment.
- gizmo686 12y ago
  >In two different formats What does this mean?
  - jeffreyrogers 12y ago
    Probably means an onsite and an offsite backup for example.
  - mdturnerphys 12y ago
    Probably different media, e.g. an external hard drive and DVDs.
- Alupis 12y ago
  Always live by the saying: "If it doesn't exist in at least three places, it doesn't actually exist" - Allan Jude - TechSnap
- colanderman 12y ago
  You're too kind :) Granted, part of the blame lies in the archaic Unix security model which doesn't sandbox applications. But ANY line containing "rm -rf" should be reviewed by the most senior dev in the company, or at least one who actually understands shell scripting. It has such a terrible failure mode, there's no excuse not to. (Especially when the dev to blame knew that it's "Scary!".)
  - balls187 12y ago
    Interesting: https://github.com/search?q=rm+-rf&type=Code&utf8=%E2%9C%93 https://github.com/search?q=rm+-rf&type=Code&utf8=%E2%9C%93
lifeisstillgood 12y ago
This is a danger of me-ware being used before it becomes software. Software assumes and defends against others using and running it. Me-ware makes no assumptions because me is the only one running it. The transition from meware to software is a hard one - and usually it's how we get terrible reputations as an industry. Basically it's a prototype till it's burned enough beta users. Edit OMG - that is actually Steam from valve - I take it back - this is supposed to be software.
- chadzawistowski 12y ago
  Though it turned out to be irrelevant, I really enjoyed your spiel about "me-ware". The distinction between it and finished software is too easy to forget.
  - lifeisstillgood 12y ago
    I'm pretty sure I stole of off the guy who wrote Source Vault SCM but his name escapes me.
rndn 12y ago
I don't want to blame anyone, but maybe there should be foolproof default security measures that prevent something like this from happening. For example rm -rf called on a home, documents, music, photos etc. directory could require an additional confirmation, perhaps through a GUI.
- SolarNet 12y ago
  There are, it's called users, and groups, and file permissions. Applications like steam should really be running under a separate user so they can't write to personal files (and maybe just have read permissions). But of course proper application isolation and file permissions is something few people do correctly on their personal machines, let alone know about. Window managers don't make it any easier, and I put a lot of the blame on them for not making it easy to configure applications to start under different users.
  - gizmo686 12y ago
    It seems like the direction Linux is going (albeit slowly) is to use selinux instead of different users for this type of isolation.
    - SolarNet 12y ago
      Yes, however linux supports this sort of security right now and has for many many years, and properly used would have prevented these mishaps. More than backing up their data, I blame the users for being incompetent users of computers in general.
      - gizmo686 12y ago
        Linus supports selinux right now, the only issue is that applications ship with policy about as often as they create their own user (actually, maybe a bit more often).
        SolarNet 12y ago
BoppreH 12y ago
A while ago I made a small program to cache Steam's grid images and search missing ones (https://github.com/boppreh/steamgrid https://github.com/boppreh/steamgrid). More of an experiment in programming in Go, really, but it works and makes Steam a little better. When I tried on Linux, it threw a permission error. Turns out Steam installs the folder "~/.local/share/Steam/userdata/[userid]/config/grid" without the executable permission bit. Without this bit no one can create files in there, Steam included, and the custom images feature gets broken. I reported the problem, saying they should fix their installer, and got a "have you tried reinstalling it?" spiel. When I said I did, and manually changing the permission fixes the problem, so it must really be it, they closed the ticket with "I am glad that the issue is resolved". This was a ticket at support.steampowered.com, because I didn't know Valve had a github account. I would open an issue there, but I don't have a linux installation to test again and this sort of misunderstanding burns a lot of goodwill.
- m_mueller 12y ago
  Too many IT supporters either have no idea what they're doing or have no interest in helping improve their product. I'm experiencing the same with highly specific and expensive commercial product, so it doesn't surprise me with Steam at all.
- NamTaf 12y ago
  Vavle's customer support is known to be pretty awful. This is all too familiar an issue. To be fair to them, when the six-sigma of your customer service is 15 year olds asking to be unbanned cause they totally didn't use hacks, your CS probably gets a bit desensitised.
- deleted 12y ago
  [deleted]
iopq 12y ago
Since this kind of thing keeps happening, isn't there a need for a safer tool than shell scripts? Maybe with a little bit more safety around null/empty variables and not as stringly typed?
- rdc12 12y ago
  Tools that are safer then shell scripts exist, doesn't mean that end users have them installed, doesn't mean people will chose to you them either
  - iopq 12y ago
    Python?
Bahamut 12y ago
It should be noted, as listed in that issue thread, this is apparently also present on Windows (same bug in two different shell scripts!).
Xylemon 12y ago
Something like this with Steam happened to my friend not too long ago. It was very saddening because he literally lost years of files (including personal projects) and salvaged what he could. That was with the Steam Beta and I caught Steam doing this myself (after he told me what happened). I was lucky to stop the script and switched out of the beta. At the time he reported this to Valve themselves and said they were "investigating the issue and knew of it". Seems to still be here, sigh. I know the morale here is keep your files backed up but come on, this is a ridiculous issue Valve still hasn't fixed.
- justizin 12y ago
  That is quite frustrating, and consumer vendors should be mindful of creating life-changing experiences. Also: backups. I know it sounds cliche, but look, if it has a mechanical hard drive, the manufacturer could have slightly mis-calibrated one of the mechanical assemblies, and this could have happened because the nature of digital storage is that it is essentially ephemeral. Protect yourself from things outside your control. You don't need the most sophisticated solution, just an external usb drive.
  - moe 12y ago
    Or if you're on a Mac you don't even need any extra hardware. Just ARQ and an AWS Account [or google drive, or dreamobjects, or SFTP, or...]. Your backup is client side encrypted and completely painless. Take half an hour to set it up and then just forget it till it saves your ass. Not affiliated, just a fan: http://www.haystacksoftware.com/arq/ http://www.haystacksoftware.com/arq/
  - Chattered 12y ago
    But if that external usb drive is mounted at the time (as in the case of the user this thread is about), then all data on that drive will be deleted. For this reason, the recommened way to use things like rsnapshot is to have your backup directories owned by root and with permissions masked to something like rwxr--r--. If you then want to read your backups easily, you do things like mount it under NFS as read-only.
codemac 12y ago
Steam in docker, anyone?
winslow 12y ago
We all make mistakes when coding. However, knowing an engineer at Valve did this in a way makes me feel a little bit better about my abilities as a software engineer. At the end of the day we are all human and makes something like working at Valve/Google/Big Name Corp a little less daunting.
natrius 12y ago
When are we moving to the mobile security model on the desktop? I love knowing that nothing I install on my phone can ever to anything like this or access data that belongs to another program in general.
lago 12y ago
this is clearly programmer error, but it's multiplied by a random variable: the Degree of Misery of the programming language, (in this case) bash.
pjc50 12y ago
For those of you worried about important files, chattr +i is a useful defence. No easy way of applying this automatically. Long ago I had a kernel hack that would kill any process that attempted to delete a canary file. Worked OK but no chance of it ever going mainstream.
- gizmo686 12y ago
  Nice. Although if I forgot I did this, I suspect that I will have a difficult time figuring out why I cannot delete the file.
- Zancarius 12y ago
  Reminds me of a shell trick I saw many years ago for short circuiting accidental 'rm -rf's by issuing a 'touch -- -i' in a sensitive location. In bash (and others), the glob operator inadvertently feeds the '-i' (now a file) into rm as an argument which then interprets it as its "interactive" flag, causing it to prompt for continued removal.
  - jjnoakes 12y ago
    Which only helps "rm -rf ". It does nothing for "rm -rf /anything" or "rm -rf /anything/" or "rm -rf /*" or any other way of spelling doom.
    - Zancarius 12y ago
      Which is why I mentioned the glob operator! Speaking of which, if you did touch '/-i', it would catch rm -rf /* Ironically, I was thinking of adding that specific directories would not be caught (obviously), but I figured that would be understood implicitly since most people ought to know what <asterisk> actually does in the shell. And if they don't... Edit: I just noticed that the glob operator in my first comment didn't show up, because it was eaten by markdown. Incidentally, so was the asterisk in your post! That might be the source of your confusion. In that case, I should specify such a trick only works with: rm -rf * rm -rf /* rm -rf ~/* Or similar. Not specific files. But, again, I appeal to the importance of understanding what the glob operator actually does! As an aside, the context of this post is a mistake in steam.sh which may essentially do: rm -rf /* So, the discussion implicitly has nothing to do with exact paths. :)

603 points by stkhlm 12y ago

If you're curious about who the "Scary!" guy is, someone pointed to where the code was checked in: https://github.com/lrusak/steam_latest/commit/21cc14158c171f5912b04b83abf41205eb804b31 https://github.com/lrusak/steam_latest/commit/21cc14158c171f...

rcxdude 12y ago
That looks like an unofficial repo. I don't think the guy who committed that actually wrote it.
wintersFright 12y ago
some hilarious comments there now

Chris_Newton 12y ago

This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data without warning in such a sweeping way. I have often made this argument in the context of sandboxing communications software like browsers and e-mail clients, where it is relatively unusual to need access to local files except for their own data. In that context, restricting access to other parts of the filesystem unless explicitly approved would be a useful defence against security vulnerabilities being exploited by data from remote sources. It’s hard to encrypt someone’s data and hold it for ransom or to upload sensitive documents if your malware-infected process gets killed the moment it starts poking around where it has no business being. More generally, I see no reason that we shouldn’t limit applications’ access to any system by default, following the basic security principle of least privilege. We have useful access control lists based on concepts of ownership by users and groups and reserving different parts of the filesystem for different people. Why can’t we also have something analogous where different files or other system resources are only accessible to applications that have been approved for that access?

andrewfong 12y ago
Isn't this the basic idea behind the sandbox in OS X? I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address. First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broader access. Second, as a corollary of the first, that means you're going to have a lot of apps that legitimately need to ask users to approve broader access. And as the number of apps asking for approval goes up, the more likely users are to simply ignore the warning and approve all. This is especially problematic since we can assume the average user is a good judge of which apps need which access. Edit: One way of reducing user acceptance fatigue might to introduce greater granularity into the requested permissions and then tier the permissions requested -- e.g. commonly asked vs. uncommon. E.g. an app may legitimately need permission to write to any file in your home directory, but it's highly unlikely they'll need permission to write to more than X number of files per second. Or at least they shouldn't be able to do so without the OS throwing up lots of warnings outside of the app.
- gizmo686 12y ago
  It helps if you assume good faith of the application developer. Part of developing an application should be defining what permissions you need at install time. This won't help against legitimate malice, but it would defend against this type of mistake, and (if it is configured such that the app cannot change its own permissions) will also mitigate any exploit of the app.
- ejdyksen 12y ago
  Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1]. For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed container. [1] https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW17 https://developer.apple.com/library/mac/documentation/Securi...

kazinator 12y ago

rm -rf "$STEAMROOT/"* This is why serious bash scripts use set -u # trap uses of unset variables Won't help with deliberately blank ones, of course. Scripting languages in which all variables are defined if you so much as breathe their names are such a scourge ... I did this once in a build script. It wiped out all of /usr/lib. Of course, it was running as root! That machine was saved by a sysadmin who had a similar installation; we copied some libs from his machine and everything was cool.

falcolas 12y ago
rm --preserve-root -rf "$STEAMROOT/"* would have worked too.
- firethief 12y ago
  Really? Have you tried it? If your shell expands globs and you have any directories below / (both very common conditions), rm will not receive any arguments that are the root directory, and your --preserve-root will not alter its behavior. --preserve-root would help if the author of this particular nugget hadn't made the additional mistake of inserting a needless /*, but with that there the root directory would never be an argument to the rm.
jzwinck 12y ago
While you're at it: set -e # exit on unchecked failure That way you don't trudge forward through an untested code path after a failure, you stop there and then.
- oblio 12y ago
  I use this holy trinity in most of my scripts: set -o nounset # set -u set -o errexit # set -e set -o pipefail # I'm not sure this has a short form. I use the long forms for the option names because they're self documenting. If anyone has more suggestions, I'm all ears.
  - drothlis 12y ago

stevewilhelm 12y ago

Many of the comments mentioned this should have been caught in the code review. I suspect they don't perform code reviews. Makes me wonder, is there a tool, system, service for auditing how many 'pair of eyes' have reviewed a given line of code. This would be hard to determine, but could be useful. I am envisioning a heatmap bar or overlay that indicates the number of reviews a line of code has received.

comboy 12y ago
I would use that. For unpopular open source projects. Let me review and comment other people code, make them review mine. Some rating is probably needed. Very nice idea.
noarchy 12y ago
It is trivial to find systems where you can assign specific people to review code, of course. Plenty exist. But to guarantee that they truly read a line of code, rather than skimmed/scrolled through it? Even if they paused their scrolling on that line, it doesn't mean that they really read it, or did so with proper understanding of what it was doing. Short of placing an actual comment or question for that line (demonstrating some real interaction), it doesn't seem like an easy problem to tackle.
- skeoh 12y ago
  I think there's merit in the idea -- not tracking what a code reviewer reads but more of tracking how many times each line of code has been _included_ in a review, by being modified or maybe within so many lines of a change (like how diffs show X lines of surrounding context). The idea would be that code changes _near_ a buggy line would be more likely to draw attention to that bug and perhaps lines with less attention would be more likely to facilitate hidden bugs.
  - jacalata 12y ago
    I suspect it would work out the other way round - code in a frequently modified section would be more likely to hold bugs because the requirements/understanding of that code is changing more frequently.

izietto 12y ago

IT reminds me the Bumblebee Project bug: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue... Spoiler: due to a forgotten space the entire /usr folder was deleted

chj 12y ago

This could be quick hack, maybe the dev just forgot to put it on the issue list.

preconsider 12y ago

To those name-calling the author of the script: The product/update is hyped and the release date is set in stone. Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals. A last-minute showstopper bug comes in, caused by file leaks. Everyone is scrambling, and the file belongs to you so its on you to fix it alone. There is no time for code review, and delaying isn't an option (so says management). "I'm afraid if we keep seeing these delays in your components, we might have to consider rehiring your position". The rm rf works -- it's a little bit scary, but it works. You write a test case, and everything passes. Still, you add the "scary" line for good measure. You have two more bugs for fix today and you'll be lucky if you're home by midnight and see your wife or kids. You've been stuck in the office and haven't seen them in days. Are you an "idiot", "talentless" engineer that "deserves to have his software engineering license permanently revoked"? How do you know this wasn't the genesis of this line of code?

click170 12y ago
This. This is the reality of corporate development. I think we should be demanding more before buying software from vendors, especially when you can't just whip out the source code to audit or fix yourself. Suff like this doesn't have to happen, but we let it.
cechner 12y ago
but the same wouldnt be acceptable in other lines of work right? Try a civil engineer or surgeon... what would you expect someone to do in similar situations? Probably escalate the issue and perhaps delay the release. Pushing in shitty broken means you're not doing your job. If your company forces you to do this then they are not doing their job.
wpietri 12y ago
Yes, that person is still an unprofessional idiot. If a doctor accidentally removes the wrong organ because administrators have overscheduled him, "whoopsie, not my fault" is not the appropriate answer. The same applies to engineers working on bridges. Professionals take responsibility for their working conditions. There is an enormous shortage of programmers right now. Anybody shipping stuff that is bad or dangerous is choosing that. If we drop our professional standards the moment a boss makes a sadface, then we're not professionals.

douche 12y ago

Why are we still running bash scripts? The only thing worse might be DOS batch files. It's not like python isn't available on every major linux distro. It's a little harder to ensure it's on windows, but when Steam is installing every point release of the Visual C++ runtime that has ever existed on my system, why not bundle python in there too?

deleted 12y ago
[deleted]
woodman 12y ago
> Why are we still running bash scripts? Because admins gotta admin. Also, adding python to a software suite just to work on the file system... gross.
mst 12y ago
And even if it isn't, modern perl would do as well as python for this case, with no language wars required.
- douche 12y ago
  Exactly. There are better options, that have more sane string and path handling. Much as I grumble about using Powershell on Windows, at least you've got the .Net framework underneath you that you can drop into relatively easily

bcantrill 12y ago

Wow, an awful bug -- and brings back memories of a very similar bug that we had back in the late 1990s at Sun. Operating system patches on Solaris were added with a program called patchadd(1M), which, as it turns out, was actually a horrific shell script, and had a line that did this: rm -rf $1/$2 Under certain kinds of bad input, the function that had this line would be called without any arguments -- and this (like the bug here) would become into "rm -rf /". This horrible, horrible bug lay in wait, until one day the compiler group shipped a patch that looked, felt and smelled like an OS patch that one would add with patchadd(1M) -- but it was in fact a tarball that needed to be applied with tar(1). One of the first systems administrators to download this patch (naturally) tried to apply it with patchadd(1M), and fell into the error case above. She had applied this on her local workstation before attempting it anywhere else, and as her machine started to rumble, she naturally assumed that the patch was busily being applied, and stepped away for a cup of coffee. You can only imagine the feeling that she must have had when she returned to a system to find that patchadd(1M) was complaining about not being able to remove certain device nodes and, most peculiarly, not being able to remove remote filesystems (!). Yes, "rm -rf /" will destroy your entire network if you let it -- and you can only imagine the administrator's reaction as it dawned on her that this was blowing away her system. Back at Sun, we were obviously horrified to hear of this. We fixed the bug (though the engineer who introduced it did try for about a second and a half to defend it), and then had a broader discussion: why the hell does the system allow itself to be blown away with "rm -rf /"?! A self-destruct button really doesn't make sense, especially when it could so easily be mistakenly pressed by a shell script. So we resolved to make "rm -rf /" error out, and we were getting the wheels turning on this when our representative to the standards bodies got wind of our effort. He pointed out that we couldn't simply do this -- that if the user asked for a recursive remove of the root directory, that's what we had to do. It's a tribute to the engineer who picked this up that he refused to be daunted by this, and he read the standard very closely. The standard says a couple of key things: 1. If an rm(1) implies the removal of multiple files, the order of that removal is undefined 2. If an rm(1) implies the removal of multiple files, and a removal of one of those files fails, the behavior with respect to the other files is undefined (that is, maybe they're removed, maybe they're not -- the whole command fails. 3. It's always illegal to remove the current directory. You might be able to imagine where we went with this: because "rm -rf /" always implies a removal of the current directory which will always fail, we "defined" our implementation to attempt this removal "first" and fail the entire operation if (when) it "failed". The net of it is that "rm -rf /" fails explicitly on Solaris and its modern derivatives (illumos, SmartOS, OmniOS, etc.): # uname -a SunOS headnode 5.11 joyent_20150113T200918Z i86pc i386 i86pc # rm -rf / rm of / is not allowed May every OS everywhere make the same improvement!

Alupis 12y ago

I've done something like this before, with my own build scripts. Except I was running as root (a requirement for some parts of the build). Part of the scripts installed a bunch of files into what was supposed to be a fakeroot, however I did not have bash's 'set -u' configured and an incorrectly spelled path variable was null, meaning something like: "${FAKEROOT}/etc" was translated into "/etc". Before I realized it, it had clobbered most of my /etc directory. When the build failed, I was puzzled. I only noticed there was an issue when I opened a new shell and instead of seeing "myuser@host ~]#" I got "noname@unknown ~]#". Uh oh... Needless to say I know do my development of those scripts from within a VM.

orblivion 12y ago

Thanks for reminding me to unmount my backup drive.

mofle 12y ago

I've written a short guide on how you should safeguard `rm`: https://github.com/sindresorhus/guides/blob/master/how-not-to-rm-yourself.md#safeguard-rm https://github.com/sindresorhus/guides/blob/master/how-not-t...

orbitingpluto 12y ago

Horrible life lesson. Saved by my own laziness.

mtsmithhn 12y ago

The sad sad part of all this is that Half-life 1 had a similar bug in their windows installer and would wipe your program files if not careful http://arstechnica.com/civis/viewtopic.php?t=479484 http://arstechnica.com/civis/viewtopic.php?t=479484

gcp 12y ago
One update to Eve Online had a broken script that removed "boot.ini" in some circumstances. Customers were not amused.
DCoder 12y ago
Myth II had a similar bug, too: http://minimaxir.com/2013/06/working-as-intended/ http://minimaxir.com/2013/06/working-as-intended/

leni536 12y ago

Well I'm on the guy's side but this worth noting: Including my 3tb external drive I back everything up to that was mounted under /media. Well maybe it was just unfortunate and the drive just happened to be mounted or the "backup" is always online. If it is the latter it is a really bad idea. If your computer is compromised you risk all of your backup. A proper backup should protect your data from these occasions.

im3w1l 12y ago

Just wanted to remind everyone that deleted files can be recovered until their space is reclaimed for something else. So if you notice something like this happening, shut down computer asap, so they can't be overwritten. Plug drive into another computer but do not mount it. Instead run some file recovery program on it. For an SSD it becomes murkier though, what with their trimming and automatic garbage collection.

nodata 12y ago
Yeah if you have time to manually guess the filenames on half a million files. Great.
- im3w1l 12y ago
  $ extundelete /dev/sda{n} --restore-all

deleted 12y ago

[deleted]

blueskin_ 12y ago

This is an amateur mistake. Makes me wonder what horrors lurk inside Steam itself...

tomaskafka 12y ago

Another beautiful example of developer/user priority inversion. All system architects ever: 1) System data are sacred, we must build a secure system of privileges disallowing anyone to touch them 2) User data are completely disposable, any user's program can delete anything. All users ever: 1) What? I can reinstall that thing in 20 minutes, there's like 100 million copies worldwide of these files. 2) These are my unique and precious files worth years of work, no one can touch them without my permission!

deleted 12y ago

[deleted]

keruspe 12y ago

Pretty sure shellcheck ( http://www.shellcheck.net/ http://www.shellcheck.net/ ) has a lot to say about this faulty script...

deeviant 12y ago

Reminds me of a bug with the Myth II uninstaller immortalized by the following Penny Arcade cartoon: http://www.penny-arcade.com/comic/1999/01/06 http://www.penny-arcade.com/comic/1999/01/06 Basically, they called delete tree. If the user installed or moved the game to a different location, say, the root, it would delete tree away somebody's whole computer. Fun times.

nodesocket 12y ago

What is this magic doing? $(cd "${0%/*}")

endgame 12y ago
It's a bashism. Open up "man bash" and search for "Remove matching suffix pattern".
- clebio 12y ago
  which, regrettably, is not something you can do with `man` if you find `${0%/*}` in a script you're reading that someone else wrote.
  - endgame 12y ago
    No, but you can find it by searching for "%", because that's exactly what I did.
DangerousPie 12y ago
$0 is the path of the script. ${0%/* } takes $0, deletes the smallest substring matching /* from the right (the filename) and returns the rest, which would be the directory of the script. So this changes the directory to the directory the script is located in.
- rjgray 12y ago
  Is there any good reason to use this approach over the more readable 'dirname $0'? Not that it would have made any difference to the bug in question of course.
- barrkel 12y ago
  $0 is not the path of the script. $0 is the path passed to the shell used to execute the script. If run via the #! line, it will contain a path of some kind. But if it's passed directly using "bash myscript.sh", then it won't. And yes, dirname is a way out of this. I'd do this: "$(cd "$(dirname "$0")"; pwd)" if I wanted the path to the script. I would also sanity-check the path by testing for the existence of some files or directories that are expected to exist under it, before trying to delete it all.

akamaka 12y ago

Here's the offending shell script code: # figure out the absolute path to the script being run a bit # non-obvious, the ${0%/*} pulls the path out of $0, cd's into the # specified directory, then uses $PWD to figure out where that # directory lives - and all this in a subshell, so we don't affect # $PWD STEAMROOT="$(cd "${0%/*}" && echo $PWD)" [...] # Scary! rm -rf "$STEAMROOT/"* The programmer knew the danger and did nothing but write the "Scary!" comment. Sad, but all-too-familiar.

ghuntley 12y ago
Offending commit @ https://github.com/lrusak/steam_latest/commit/21cc14158c171f5912b04b83abf41205eb804b31#diff-9f48ba7f3b9e90e945e5b1fe7654c74cR358 https://github.com/lrusak/steam_latest/commit/21cc14158c171f...
- zamalek 12y ago
  The reaction images/memes are priceless.
- gcp 12y ago
  Actually, that repo is just a user who extracted the Steam .debs into a github repo, the comments are completely misdirected.
Qantourisc 12y ago
Whenever I write something scary like that, I usually wrap it in a function, double checking if it's really the folder you wish to delete ... Often even adding a user-verification if possible.
iamtew 12y ago
Since the script is written in bash they could also have used $BASH_SOURCE, which will always point to the correct path of the script being executed, so you can do something like this: SCRIPT="$BASH_SOURCE" SCRIPT_DIR="$(dirname "$BASH_SOURCE")"
deeviant 12y ago

colanderman 12y ago

# Scary! rm -rf "$STEAMROOT/"* Anybody who writes a line like this deserves their software engineer license revoked. This isn't the first time I've seen shit like this (I've seen it in scripts expected to be run as root, no less); it makes my blood boil. Seriously. "xargs rm -df -- < MANIFEST" is not that hard. EDIT: I shouldn't be so harsh, if it weren't for the comment admitting knowing how poor an idea this line is.

Guthur 12y ago
Is there proof that the comment was committed with the line of code? Of course once it was a identified a concerted effort could have been made to rectify the situation. Sometimes a problem is identified working on some unrelated aspect of the software and the developer does not have time or scope to change the offending piece of code but wants to place a red flag. Of course this example does not appear to be systematic approach to marking "fixme", unless of course their fixme tag is actually #scary. Edit: Of course one would hope they have raised a rather high priority work item for this.
- deleted 12y ago
  [deleted]
irishcoffee 12y ago
The programmer committed a cardinal sin to be sure. But, so did everyone on the code review that let it slide.
- noarchy 12y ago
  Do we know if they do code review? Are pull requests blindly accepted?
  - irishcoffee 12y ago
    If valve doesn't do code reviews, and if pull requests are actually blindly accepted (is that actually a thing? Do people ever actually blindly accept pull requests?) I don't think I have the wherewithal to give a useful response.

fsaintjacques 12y ago

Note to all, prepend all your bash script with "set -o errexit -o nounset -o pipefail" It'll save you headaches.

shawkinaw 12y ago
Yep, my thought exactly. My standard bash header is #!/bin/bash set -eu IFS=$'\n\t' (Wish there was a shorthand version of pipefail, then I'd always use that too.)
- LeoPanthera 12y ago
  You can save a line by doing #!/bin/bash -eu
  - krotton 12y ago
    Which is no equivalent if the script is executed using "bash script.sh" ;).
mod 12y ago
Can you at least explain what this is doing, outside of saving me headaches?
- barsonme 12y ago
  set -o errexit (set -e): exit script when command fails set -o nounset (set -u): exit script when it tries to use undeclared variables set -o pipefail: returns error from pipe `|` if any of the commands in the pipe fail (normally just returns an error if the last fails)
- redsymbol 12y ago
  http://redsymbol.net/articles/unofficial-bash-strict-mode/ http://redsymbol.net/articles/unofficial-bash-strict-mode/
- Anderkent 12y ago

jtokoph 12y ago

The biggest lesson here is that backing up your files is extremely important. Both local backups and remote backups. I like the 3-2-1 rule: At least three copies, In two different formats, with one of those copies off-site. Software is written by humans who will undoubtably miss a corner case and not think of every possible environment.

gizmo686 12y ago
>In two different formats What does this mean?
- jeffreyrogers 12y ago
  Probably means an onsite and an offsite backup for example.
- mdturnerphys 12y ago
  Probably different media, e.g. an external hard drive and DVDs.
Alupis 12y ago
Always live by the saying: "If it doesn't exist in at least three places, it doesn't actually exist" - Allan Jude - TechSnap
colanderman 12y ago
You're too kind :) Granted, part of the blame lies in the archaic Unix security model which doesn't sandbox applications. But ANY line containing "rm -rf" should be reviewed by the most senior dev in the company, or at least one who actually understands shell scripting. It has such a terrible failure mode, there's no excuse not to. (Especially when the dev to blame knew that it's "Scary!".)
- balls187 12y ago
  Interesting: https://github.com/search?q=rm+-rf&type=Code&utf8=%E2%9C%93 https://github.com/search?q=rm+-rf&type=Code&utf8=%E2%9C%93

lifeisstillgood 12y ago

This is a danger of me-ware being used before it becomes software. Software assumes and defends against others using and running it. Me-ware makes no assumptions because me is the only one running it. The transition from meware to software is a hard one - and usually it's how we get terrible reputations as an industry. Basically it's a prototype till it's burned enough beta users. Edit OMG - that is actually Steam from valve - I take it back - this is supposed to be software.

chadzawistowski 12y ago
Though it turned out to be irrelevant, I really enjoyed your spiel about "me-ware". The distinction between it and finished software is too easy to forget.
- lifeisstillgood 12y ago
  I'm pretty sure I stole of off the guy who wrote Source Vault SCM but his name escapes me.

rndn 12y ago

I don't want to blame anyone, but maybe there should be foolproof default security measures that prevent something like this from happening. For example rm -rf called on a home, documents, music, photos etc. directory could require an additional confirmation, perhaps through a GUI.

SolarNet 12y ago
There are, it's called users, and groups, and file permissions. Applications like steam should really be running under a separate user so they can't write to personal files (and maybe just have read permissions). But of course proper application isolation and file permissions is something few people do correctly on their personal machines, let alone know about. Window managers don't make it any easier, and I put a lot of the blame on them for not making it easy to configure applications to start under different users.
- gizmo686 12y ago
  It seems like the direction Linux is going (albeit slowly) is to use selinux instead of different users for this type of isolation.
  - SolarNet 12y ago
    Yes, however linux supports this sort of security right now and has for many many years, and properly used would have prevented these mishaps. More than backing up their data, I blame the users for being incompetent users of computers in general.
    - gizmo686 12y ago
      Linus supports selinux right now, the only issue is that applications ship with policy about as often as they create their own user (actually, maybe a bit more often).
      - SolarNet 12y ago

BoppreH 12y ago

A while ago I made a small program to cache Steam's grid images and search missing ones (https://github.com/boppreh/steamgrid https://github.com/boppreh/steamgrid). More of an experiment in programming in Go, really, but it works and makes Steam a little better. When I tried on Linux, it threw a permission error. Turns out Steam installs the folder "~/.local/share/Steam/userdata/[userid]/config/grid" without the executable permission bit. Without this bit no one can create files in there, Steam included, and the custom images feature gets broken. I reported the problem, saying they should fix their installer, and got a "have you tried reinstalling it?" spiel. When I said I did, and manually changing the permission fixes the problem, so it must really be it, they closed the ticket with "I am glad that the issue is resolved". This was a ticket at support.steampowered.com, because I didn't know Valve had a github account. I would open an issue there, but I don't have a linux installation to test again and this sort of misunderstanding burns a lot of goodwill.

m_mueller 12y ago
Too many IT supporters either have no idea what they're doing or have no interest in helping improve their product. I'm experiencing the same with highly specific and expensive commercial product, so it doesn't surprise me with Steam at all.
NamTaf 12y ago
Vavle's customer support is known to be pretty awful. This is all too familiar an issue. To be fair to them, when the six-sigma of your customer service is 15 year olds asking to be unbanned cause they totally didn't use hacks, your CS probably gets a bit desensitised.
deleted 12y ago
[deleted]

iopq 12y ago

Since this kind of thing keeps happening, isn't there a need for a safer tool than shell scripts? Maybe with a little bit more safety around null/empty variables and not as stringly typed?

rdc12 12y ago
Tools that are safer then shell scripts exist, doesn't mean that end users have them installed, doesn't mean people will chose to you them either
- iopq 12y ago
  Python?

Bahamut 12y ago

It should be noted, as listed in that issue thread, this is apparently also present on Windows (same bug in two different shell scripts!).

Xylemon 12y ago

Something like this with Steam happened to my friend not too long ago. It was very saddening because he literally lost years of files (including personal projects) and salvaged what he could. That was with the Steam Beta and I caught Steam doing this myself (after he told me what happened). I was lucky to stop the script and switched out of the beta. At the time he reported this to Valve themselves and said they were "investigating the issue and knew of it". Seems to still be here, sigh. I know the morale here is keep your files backed up but come on, this is a ridiculous issue Valve still hasn't fixed.

justizin 12y ago
That is quite frustrating, and consumer vendors should be mindful of creating life-changing experiences. Also: backups. I know it sounds cliche, but look, if it has a mechanical hard drive, the manufacturer could have slightly mis-calibrated one of the mechanical assemblies, and this could have happened because the nature of digital storage is that it is essentially ephemeral. Protect yourself from things outside your control. You don't need the most sophisticated solution, just an external usb drive.
- moe 12y ago
  Or if you're on a Mac you don't even need any extra hardware. Just ARQ and an AWS Account [or google drive, or dreamobjects, or SFTP, or...]. Your backup is client side encrypted and completely painless. Take half an hour to set it up and then just forget it till it saves your ass. Not affiliated, just a fan: http://www.haystacksoftware.com/arq/ http://www.haystacksoftware.com/arq/
- Chattered 12y ago
  But if that external usb drive is mounted at the time (as in the case of the user this thread is about), then all data on that drive will be deleted. For this reason, the recommened way to use things like rsnapshot is to have your backup directories owned by root and with permissions masked to something like rwxr--r--. If you then want to read your backups easily, you do things like mount it under NFS as read-only.

codemac 12y ago

Steam in docker, anyone?

winslow 12y ago

We all make mistakes when coding. However, knowing an engineer at Valve did this in a way makes me feel a little bit better about my abilities as a software engineer. At the end of the day we are all human and makes something like working at Valve/Google/Big Name Corp a little less daunting.

natrius 12y ago

When are we moving to the mobile security model on the desktop? I love knowing that nothing I install on my phone can ever to anything like this or access data that belongs to another program in general.

lago 12y ago

this is clearly programmer error, but it's multiplied by a random variable: the Degree of Misery of the programming language, (in this case) bash.

pjc50 12y ago

For those of you worried about important files, chattr +i is a useful defence. No easy way of applying this automatically. Long ago I had a kernel hack that would kill any process that attempted to delete a canary file. Worked OK but no chance of it ever going mainstream.

gizmo686 12y ago
Nice. Although if I forgot I did this, I suspect that I will have a difficult time figuring out why I cannot delete the file.
Zancarius 12y ago
Reminds me of a shell trick I saw many years ago for short circuiting accidental 'rm -rf's by issuing a 'touch -- -i' in a sensitive location. In bash (and others), the glob operator inadvertently feeds the '-i' (now a file) into rm as an argument which then interprets it as its "interactive" flag, causing it to prompt for continued removal.
- jjnoakes 12y ago
  Which only helps "rm -rf ". It does nothing for "rm -rf /anything" or "rm -rf /anything/" or "rm -rf /*" or any other way of spelling doom.
  - Zancarius 12y ago
    Which is why I mentioned the glob operator! Speaking of which, if you did touch '/-i', it would catch rm -rf /* Ironically, I was thinking of adding that specific directories would not be caught (obviously), but I figured that would be understood implicitly since most people ought to know what <asterisk> actually does in the shell. And if they don't... Edit: I just noticed that the glob operator in my first comment didn't show up, because it was eaten by markdown. Incidentally, so was the asterisk in your post! That might be the source of your confusion. In that case, I should specify such a trick only works with: rm -rf * rm -rf /* rm -rf ~/* Or similar. Not specific files. But, again, I appeal to the importance of understanding what the glob operator actually does! As an aside, the context of this post is a mistake in steam.sh which may essentially do: rm -rf /* So, the discussion implicitly has nothing to do with exact paths. :)