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.

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

    10. Re:When I see that [literaly] textbook mistake.... by greg1104 · · Score: 3, Insightful

      Checking if STEAMROOT is an empty string is a good start, but it's still not enough. Anything that's unleashing something as dangerous as "rm -rf" should do a serious sanity check first. Looking at the text name of the directory, seeing if it's really a directory, or seeing if you can cd into it (and the output from pwd still matches) are all useful checks. But you will still find edge cases where they do terrible things in the real world.

      As an example of something more robust, PostgreSQL does what it can to deal with this problem by having a file named PG_VERSION in every installed database directory tree. All utilities that do something scary take the directory provided and check to see if there's a PG_VERSION file in there. If not, abort, saying that the structure expected isn't there. Everything less complicated than that occasionally ate people's files. A common source of trouble here for database servers is when there was a race condition against a NFS mount, so that it showed up in the middle of when the script was running.

      When you stare at that sort of problem long enough, no check for whether your incoming data is sensible is good enough. You must looking for a positive match on a "I see exactly the data I expect" test of the directory tree instead, before wiping out files in particular. Even the level of paranoia in Postgres is still not good enough in one case. It can wipe things if you run the new database initialization step and hit one of those mount race conditions. For that reason, the initialize database setup is never run in the init scripts anymore, no matter how many complaints we get that it should be automatic.

      I first saw this class of bug in IBM's Directory software, in its RPM uninstaller. It asked RPM what directory the software was installed in, then ran "rm -rf $INSTALLDIR/data". Problem: RedHat 8.0 had a bug where that RPM query returned nothing. Guess what was in /data on the server? That's right, the 1TB of image data that server ran against. (And to put the scale of that into perspective...this was 2003, when 1TB was not a trivial amount)

  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 jeffmflanagan · · Score: 4, Informative

      It can't erase backups. Backups are offline. He imagined that an attached hard drive was backup. It is not.

    5. Re:And that people... by f3rret · · Score: 4, Funny

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

      so if you have 1 you have 0.

      So...apparently I have -1 backups, does this mean I owe the universe a backup?

      --
      Admit nothing. Deny Everything. Make Counter-accusations.
    6. Re:And that people... by mwvdlee · · Score: 4, Interesting

      It is. It just protects against fewer problems.

      Every type of backup method has drawbacks and benefits.
      If there existed a perfect backup method, we would have only that method.

      Redundancy makes it very easy and fast to recover data, but lacks security against localized physical problems and malicious software. It would be a perfectly valid first layer of backup and sufficient for backing up reproducable information such as downloaded/scanned/ripped media. It protects against accidentally deleting files or hardware problems. For less easily reproducable information you probably want some additional backup layers.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    7. Re:And that people... by BarbaraHudson · · Score: 4, Insightful

      They can be plugged in but not mounted. in such a case, rm -rf / won't touch them. Only mount the disk when doing a backup, then unmount it again, problem solved.

      --
      "Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
    8. Re:And that people... by Gibgezr · · Score: 5, Funny

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

  3. Gotta love Valve by Anonymous Coward · · Score: 4, Funny

    Screw over people on Windows with micro-transactions and useless updates, screw over people on Mac with games that run poorly, screw over people on Linux by wiping files. It's like, the less popular your OS of choice, the more shafting you get.

  4. All part of the Steam Doomsday Device by NotDrWho · · Score: 4, Funny

    Attention user, Steam has detected unusual activity on your part that could be construed as part of an effort to hack Steam. Therefore, Steam has deployed the Doomsday Device on your machine. You now have 5 minutes to either comply with out request to restore Steam to its original folder or to send a bionic person to shut down the Doomsday Device at the source. Otherwise, your system will be wiped and FBI agents will be arriving at your home shortly. Please keep your hands in the yellow circles pending their arrival. And thank you for using Steam!

    --
    SJW's don't eliminate discrimination. They just expropriate it for themselves.
    1. 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.

  5. First day of *nix training... by Assmasher · · Score: 3, Informative

    Okay children, I'm going to teach you this command explicitly so that you know what you never, ever, EVER - wake up little Johnny - what was I saying? Oh yeah, ever, ever use it.

    Seriously. Don't use it.

    --
    Loading...
    1. Re:First day of *nix training... by cliffjumper222 · · Score: 4, Funny

      Has anyone actually gone into root and executed the command-that-shall-not-be-named? It's like being in a slow-motion train-wreck. I'd like to say I did it once just to see what would happen, but that would be a lie. I was a fresh-faced admin on a Solaris workstation with root access cleaning up the hard drive of extraneous data. Imagine the scene: the finger comes down in slow motion, the Enter key depresses and a few microseconds after, everything speeds up to real time as the brain realizes what just happened. That little bit of skin between your legs crushes up and you feel like your guts are falling out of your body. You rapidly try to find the process and kill it before those very commands get wiped, but it's too late....

  6. Not the first time by Rick+Zeman · · Score: 4, Informative

    Apple had a bug like that in the iTunes installer sometime back that did exactly that: a rm -rf from root as root. Theirs came from if you had a space in your hard drive name.

    1. Re:Not the first time by sootman · · Score: 4, Informative

      It was in the updater for iTunes 2, and if you a) had your library on a second hard drive and b) if the hard drive had a space for the *first character* of the name (eg, " Music") it would erase the drive.

      http://www.xlr8yourmac.com/OSX...

      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
  7. Re:unexpected deletion by tnk1 · · Score: 4, Funny

    They need to have system administrators working for them, apparently. Not using that command is so ingrained, that I have the nightmare where I type "rm -rf /" in a console instead of the dream where you are naked in front of the class, or the one where you didn't study for finals.

    I also have the one where I run the endless loop of opening more and more xterms until my SPARCstation falls over.

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

  9. 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).

  10. Re:arguably steam isnt for linux. by DRJlaw · · Score: 3, Insightful

    [Steam] as a proprietary application expects in this case to invoke the GPL mantra of usability without warranty.

    I could have sworn that that mantra appeared in BSD licenses well before the GPL was a twinkle in RMS' eye. Yep.

    If I cared to research it, I'm certain I would find similar language in proprietary licenses which predate even that.

    Your distinction between "on" and "for" is equally myopic and artificial. Binaries "for" an operating system is used so commonly it is only questioned by ideological zealots, which most of us are not.

  11. man rm by shess · · Score: 4, Interesting

    From the rm(1) man page on most Linux distros:
                  --no-preserve-root do not treat '/' specially (the default)

                  --preserve-root
                        fail to operate recursively on '/'

    Why --preserve-root isn't the default is beyond me, since it would be generally faster to re-create the filesystem if that's what you _really_ wanted.

    1. Re:man rm by Anonymous Coward · · Score: 3, Insightful

      That doesn't matter in this case, since "rm -rf /*" is trying to delete all the subdirectories of /, not / itself.

      The rm command sees the command as this (for my machine):

      rm -rf /bin /boot /dev /etc /home /initrd.img /initrd.img.old /lib /lib32 /lib64 /libx32 /lost+found /media /mnt /opt /proc /root /run /sbin /srv /sys /tmp /usr /var /vmlinuz /vmlinuz.old

    2. Re:man rm by steelfood · · Score: 4, Informative

      Not that it would've helped in this case.

      rm -rf $var/* has two flaws. The first is if $var is blank or undefined. The second is the extra unnecessary /* that circumvents --preserve-root.

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
  12. Re:arguably steam isnt for linux. by fuzzyfuzzyfungus · · Score: 4, Insightful

    Aside from areas where it's legally unavoidable(medical devices, avionics, probably some nuclear applications), applications that take the slightest responsibility for their actions are virtually unheard of, under any license. On a good day, a proprietary application might accept liability up to the value of a refund; but not further, if it fucks up really egregiously; but that's about the extent of it.

    You can get software that promises more; but it will cost you mightily.

  13. Re:I hope no one runs steam as root. by fuzzyfuzzyfungus · · Score: 3, Insightful

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

    This is a fairly serious hole in a lot of traditional security mechanisms, blowing away the entire OS is easy, replacing the documents that any process running as you can scribble on is hard; but SELinux could definitely be used to contain the damage in a situation like this.

    With SELinux, even if Steam is running as the user, its process could run in a different domain, and have access exclusively to files in the appropriate security context(presumably only the ones it created in the first place).

    You could also use the hackier; but simpler, method of running the steam process under a different user account; but(especially once X enters the picture and you want integration with your DE's menus and whatnot) that gets kind of gross.

  14. Re:unexpected deletion by kenaaker · · Score: 4, Funny
    Or, there's this variation I used while trying to remove a bunch of . (hidden) directories from a user directory. As root of course, otherwise it's not nearly as funny.

    rm -rf .*

    The key fact is that .. matches .*

  15. Re: When I see that [literaly] textbook mistake... by Trepidity · · Score: 4, Interesting

    That tends to be too restricted for things to actually run, alas. For example, something in a chroot can't even see libc or use standard Unix utilities on its own files, because /lib and /bin are outside of the chroot. You end up having to install a whole second copy of Linux inside the chroot...

    --
    10 PRINT CHR$(205.5+RND(1)); : GOTO 10
  16. Windows installer has a similar "feature" by janoc · · Score: 3, Insightful

    The Windows installer has a similar issue and apparently it is not even considered as a problem (red box):

    https://support.steampowered.c...

    This reeks of serious incompetence or negligence, in my opinion - writing installers that blindly mass-erase files instead of tracking which files did the software actually install and erase only those on uninstall/move is not acceptable in my book. Whether or not it is documented in some disclaimer that nobody reads or not is irrelevant. This really is asking for a lawsuit if someone gets seriously bitten by it.

    I really wonder what the devs at Valve were smoking when they consider this as acceptable.

  17. shell scripts by ssam · · Score: 3, Funny

    And yet some people still cling on to shell scripts for their boot system.

  18. Re: When I see that [literaly] textbook mistake... by ganjadude · · Score: 4, Funny

    yo dawg, I heard you liked linux, so we are putting linux in yo linux!....

    --
    have you seen my sig? there are many others like it but none that are the same
  19. Re: When I see that [literaly] textbook mistake... by corychristison · · Score: 3, Interesting

    From what I understand, this is how Android works. Every app gets its own user and group.

    It is also, sort of, how Docker works. Each app gets its own container, the app is completely bound to that container. Docker manages access to outside resources (like the network) for you, utilizing cgroups, and kernelspace drivers.

  20. Re: When I see that [literaly] textbook mistake... by Wootery · · Score: 3, Interesting

    I was hoping someone would mention Android.

    Just a pity Android doesn't let you do anything meaningful with that well-designed permissions infrastructure...

    For instance, you either trust an app with your entire contacts-list, or your contacts-list is out-of-bounds entirely. There no way to 'Add contact to app', and have that launch a trusted contact-selector utility.