Slashdot Mirror

← Back to Stories (view on slashdot.org)

Steam For Linux Bug Wipes Out All of a User's Files

Posted by Soulskill on from the big-oops dept.

An anonymous reader sends a report of a bug in Steam's Linux client that will accidentally wipe all of a user's files if they move their Steam folder. According to the bug report: I launched steam. It did not launch, it offered to let me browse, and still could not find it when I pointed to the new location. Steam crashed. I restarted it. It re-installed itself and everything looked great. Until I looked and saw that steam had apparently deleted everything owned by my user recursively from the root directory. Including my 3tb external drive I back everything up to that was mounted under /media. Another user reported a similar problem — losing his home directory — and problems with the script were found: at some point, the Steam script sets $STEAMROOT as the directory containing all Steam's data, then runs rm -rf "$STEAMROOT/"* later on. If Steam has been moved, $STEAMROOT returns as empty, resulting in rm -rf "/"* which causes the unexpected deletion.

18 of 329 comments (clear)

  1. When I see that [literaly] textbook mistake.... by Art+Popp · · Score: 5, Funny

    I can hear the Steam dev. shop manager:

    Carl! Put the bullhorn down! Dave! Quit staring at Lucy and get back to wark! Kevin! We have to ship this code in TWO DAYS! Jerry! Don't point that over here!

    1. Re:When I see that [literaly] textbook mistake.... by binarylarry · · Score: 5, Funny

      Larry! Quit sniffing glue and get back to writing that steam root mover script pronto!

      --
      Mod me down, my New Earth Global Warmingist friends!
    2. Re:When I see that [literaly] textbook mistake.... by TomTraynor · · Score: 5, Informative

      Really? Really doing a delete and you don't check the existence of the folder before you start? I am not a Unix/Linux scripting expert (just a very dangerous amateur), but, I always test to see if the directory is there before I even start my scripts. If the folder isn't there the script screams, rants and raves to the console and then stops before it even starts processing. Common code I do for most Z/OS BASH scripts at the start before I even run the rest of the script:

      1. Is the folder(s) there that I need.
      2. Do I have the proper access to the folder(s)/file(s).

      If either two fail I dump to the console full information on what happened and what I think should be done to fix the problem.

      It is a common set I use ->

      Directory test:

      if test -d $1
      then
          exit ;
      else
          uExit=128
      fi;

      File existence check:

      if test -f $1
      then
          exit ;
      else
          uExit=128
      fi;

      Can I read the file:

      if test -r $1
      then
          exit ;
      else
          uExit=128
      fi;

      Not pretty, probably can be coded better, but, this works for me and saved my ass a few times.

      --
      Panic now, beat the rush!
    3. Re:When I see that [literaly] textbook mistake.... by houghi · · Score: 5, Funny

      The driectory / existed

      --
      Don't fight for your country, if your country does not fight for you.
    4. Re:When I see that [literaly] textbook mistake.... by TomTraynor · · Score: 5, Insightful

      Yep, but, they should test to see if the variable has a value. I remember vaguely that I tested for something like that by appending a value to the end saving it to a new variable and then testing both the original and new and if the same it was null.

      --
      Panic now, beat the rush!
    5. Re:When I see that [literaly] textbook mistake.... by Anonymous Coward · · Score: 5, Insightful

      if [ -z "$STEAMROOT" ] ; then echo 'you fucking idiot what are you doing'; fi

    6. Re:When I see that [literaly] textbook mistake.... by zifferent · · Score: 5, Informative

      Root? No. It deleted his home folder. Don't need root for that. Any user can raze their own home folder.

      --
      cat sig > /dev/null
    7. Re:When I see that [literaly] textbook mistake.... by Trepidity · · Score: 5, Interesting

      Does show a longstanding problem with the Unix security model, though: nothing more fine-grained than per-user permissions. There's no reason Steam should be able to delete (or even read) anything in my home directory other than its own files, but the only real way to keep it from doing so using straight Unix permissions is to create a new local user for every application.

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    8. Re:When I see that [literaly] textbook mistake.... by Anonymous Coward · · Score: 5, Informative

      That's not a problem with the model, you should own everything in your home directory. One of the irritating things about Windows is that you can't necessarily delete all the files. Some of the files aren't deletable no matter what account you use, even being admin won't work.

      In this case, giving the directory it's own Steam UID ownership would prevent Steam from deleting things that it shouldn't be deleting. You can then have the user be a member of the group that Steam belongs to and give that group the ability to change permissions. At which point, the desired behavior is easy and undesired behavior is much harder.

      Why it is that people still have these kinds of issues is beyond me, the traditional model handles things like this without much trouble, as long as you actually know what you're doing.

    9. Re:When I see that [literaly] textbook mistake.... by ejasons · · Score: 5, Insightful

      OSX sandboxed apps cannot look outside of their own directories. However, when the user chooses a file via the "Open" dialog, the application is given a handle that allows it to open just that particular file. Sandboxing really is the solution to this kind of mess...

  2. And that people... by omfg-no · · Score: 5, Insightful

    Is why you have backups. You need to apply the rule Total Backups = Total Backups -1 so if you have 1 you have 0.

    1. Re:And that people... by beelsebob · · Score: 5, Insightful

      And also, why redundancy is not backup. If your backup is plugged in and/or mounted, it's not a backup any more.

    2. Re:And that people... by MetalliQaZ · · Score: 5, Insightful

      so if you have 1 you have 0.

      Dude, what does that even mean? Backups have to be done intelligently based on your situation. In the summary, the user had an external hard disk on USB which would have protected against primary HD failure, but not against common mode failures such as a fire at home or a compromised PC. He didn't protect himself against malicious code, and got burned. The raw number of backups don't matter if you're not paying attention to what you are and are not protecting against.

      --
      "Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
    3. Re:And that people... by CanHasDIY · · Score: 5, Insightful

      Did you read the part where it also erased his backups?

      I think the moral here is, don't leave your backup drive plugged in when you're not running backups.

      --
      An enigma, wrapped in a riddle, shrouded in bacon and cheese
    4. Re:And that people... by Gibgezr · · Score: 5, Funny

      Or you have underflowed, and have 4,294,967,295 backups.

  3. Re:All part of the Steam Doomsday Device by tnk1 · · Score: 5, Funny

    Negative. I am a meat Popscicle.

    The Steam user is one door down.

  4. Re:I hope no one runs steam as root. by Anonymous Coward · · Score: 5, Insightful

    Who cares about root! My home directory is WAY more important than the system.

  5. A few if statements needed... by rklrkl · · Score: 5, Informative

    Something like this might have helped:

    if [ "$STEAMROOT" != "" -a "$STEAMROOT" != "/" ]
    then
              if [ -d "$STEAMROOT" ]
            then ...do your evil deletion of $STEAMROOT here
            fi
    fi

    Should avoid at least a full deletion traversal of the filestore, but it's still got a risk that $STEAMROOT might be ~username (or /tmp, which is less critical).