Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Bug Software Linux

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

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.
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Art Popp ( 29075 ) * on Friday January 16, 2015 @10:15AM (#48829623)

    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!

    • by binarylarry ( 1338699 ) on Friday January 16, 2015 @10:36AM (#48829899)

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

    • by TomTraynor ( 82129 ) <thomas.traynor@gmail.com> on Friday January 16, 2015 @10:38AM (#48829917)

      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.

      • by account_deleted ( 4530225 ) on Friday January 16, 2015 @10:40AM (#48829949)
        Comment removed based on user account deletion
        • 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.

          • by Anonymous Coward on Friday January 16, 2015 @10:51AM (#48830091)

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

          • 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)

      • how about:

        if [ ! -z "$STEAMROOT" ]
        then...

      • This should have been picked up in testing.......... looks like they didn;t do much
    • by Z00L00K ( 682162 )

      The only remedy would be to have a specific gaming account.

      Then only files which that account had write access to would have been in danger.

      Even better is to run under 'chroot' to protect from such mistakes. 'chroot' isn't perfect, but at least it makes it harder to mess up.

  • And that people... (Score:5, Insightful)

    by omfg-no ( 1848750 ) on Friday January 16, 2015 @10:19AM (#48829665)
    Is why you have backups. You need to apply the rule Total Backups = Total Backups -1 so if you have 1 you have 0.
    • by beelsebob ( 529313 ) on Friday January 16, 2015 @10:31AM (#48829827)

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

      • by mwvdlee ( 775178 ) on Friday January 16, 2015 @10:46AM (#48830041) Homepage

        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.

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

        That's not strictly true anymore. True, a RAID user would've been screwed in this scenario. But newer redundant filesystems like ZFS and btrfs support snapshots, which would in fact have made this situation recoverable. Provided you were generating snapshots at regular intervals.

    • by MetalliQaZ ( 539913 ) on Friday January 16, 2015 @10:31AM (#48829835)

      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.

      • Ah, but you're not factoring in the perversity of the universe - having absolutely critical files destroyed in one location increases the odds that an unrelated event will have destroyed your only backup by at least three and as many as seven orders of magnitude. Each additional backup reduces that chance (per backup) by one to two orders of magnitude, depending on the exact degree of reliability: higher reliability spits in the face of Fate, which pisses her off and increases the odds that she'll arrange

      • It obviously means "assume one backup is bad". Backup media fails too after all.

        Sure that's not enough for a silver bullet. But can you really not understand that simple statement (you don't have to agree of course)?

    • by CanHasDIY ( 1672858 ) on Friday January 16, 2015 @10:31AM (#48829837) Homepage Journal

      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.

      • by Jeff Flanagan ( 2981883 ) on Friday January 16, 2015 @10:36AM (#48829887)
        It can't erase backups. Backups are offline. He imagined that an attached hard drive was backup. It is not.
      • They were not backups. If they're plugged in, they're merely redundancy.

      • Comment removed based on user account deletion
        • by rwa2 ( 4391 ) *

          Nice setup. I'd go a step further and buy a HD for a trusted friend and rsync a snapshot of my home dir to their box, gnupg encrypted if you want.

          There's also AWS Glacier that I use for semi-annual dumps for photo archives and other things that don't change. The SAGU java client is relatively straightforward, and I save the manifest in 1-2 cloud storage services. I think 10GB worth of stuff is costing me about 47 per month... most of the cost is just incurred during retrieval, so it's a pretty good deal

        • by hawguy ( 1600213 )

          So even though they are not unplugged, they are either read-only or not mounted. Also data is available on two devices. So even if one explodes, the other is still there. No, I do not do offsite backup. If my house burns down, I have bigger issues then data.

          Depends what that data is -- when my sister lost her house in a fire (even the fire safe melted, all that was left was the fireplace and half of the 1920's era cast iron stove), she lost a *lot* of irreplaceable photos that she had scanned in over the years. Hundreds of old family photos dating back nearly 100 years -- she had the originals carefully packed away for safe keeping. Fortunately, most of her more recent photos were also stored in online photo albums so those were saved.

          She was smart enough to k

    • by f3rret ( 1776822 ) on Friday January 16, 2015 @10:41AM (#48829959)

      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?

  • by Anonymous Coward on Friday January 16, 2015 @10:19AM (#48829673)

    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.

  • by NotDrWho ( 3543773 ) on Friday January 16, 2015 @10:23AM (#48829721)

    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!

  • by lengel ( 519399 )

    Wow! That is all.

  • OTOH, running it on an SeLinux system would probably contain the damage.

    • by Anonymous Coward on Friday January 16, 2015 @10:36AM (#48829889)

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

      • by fuzzyfuzzyfungus ( 1223518 ) on Friday January 16, 2015 @11:20AM (#48830453) Journal

        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.

    • Yeah a user posted the results of that on the Steam bug tracker. It halted trying to remove a file in /boot, which I assume was the first attempt at a deletion.
    • How would that have contained the damage? His home directory files are what is important not the system files.

  • by Assmasher ( 456699 ) on Friday January 16, 2015 @10:26AM (#48829765) Journal

    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.

    • by cliffjumper222 ( 229876 ) on Friday January 16, 2015 @01:05PM (#48831791)

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

      • The best part is that since the deletion normally runs alphabetically, one of the first files taken out is /bin/kill

  • by Ecuador ( 740021 ) on Friday January 16, 2015 @10:28AM (#48829801) Homepage
    You don't even need to check $STEAMROOT, I mean what could possibly go wrong...
    But still for extra points the script should have asked to run as root...
    And a little advice to Valve, next time have developers familiar with Linux working on your Linux client. That /* is how a Windows developer would write the command to delete a directory if they simply looked up the equivalent command for Linux.
    • by jandrese ( 485 )
      Yeah, that's some straight up sloppy coding. Then again, this comes from the company who's simple storefront and game launcher app still manages to require 100MB of heap and takes several seconds to start on a fast and powerful modern machine with a SSD.
      • Many (all?) of the things the Steam client displays are webpages and thus it contains a web browser and those are heavy beats. I believe that's the reason the Steam client uses so much RAM
    • by flink ( 18449 )

      And a little advice to Valve, next time have developers familiar with Linux working on your Linux client. That /* is how a Windows developer would write the command to delete a directory if they simply looked up the equivalent command for Linux.

      A competent Windows developer would probably just write:
      if exist "%STEAMROOT%" rmdir /Q /S "%STEAMROOT%"
      no dangerous glob needed.

      It kind of floors me that they aren't doing some kind of check that the directory tree they are about to delete actually looks like a Steam install before deleting it. e.g. check that ClientRegistry.blob file or SteamApps directory exists under $STEAMHOME.

      • It kind of floors me that they aren't doing some kind of check that the directory tree they are about to delete actually looks like a Steam install before deleting it. e.g. check that ClientRegistry.blob file or SteamApps directory exists under $STEAMHOME.

        ClientRegistry.blob isn't used by Steam any more and thus won't exist if you've installed Steam in the past 9 months or so

        Would the Steam directory even have a SteamApps directory if you're using Steam's library feature to install all games to a different path?

        While we're at it, is it SteamApps, steamapps, or some other variation of capitalization? That kinda matters on Linux.

  • Not the first time (Score:5, Informative)

    by Rick Zeman ( 15628 ) on Friday January 16, 2015 @10:30AM (#48829817)

    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.

  • by rklrkl ( 554527 ) on Friday January 16, 2015 @10:38AM (#48829909) Homepage

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

  • They just left out the ampersand.

    Easy fix.

  • I would figure that --no-preserve-root would be required to delete root directory?

  • by Slamtilt ( 17405 ) on Friday January 16, 2015 @10:47AM (#48830045)

    Remember back in the day when the Sierra uninstall utility could accidentally delete all your files? I think that was a result if you put it in a non-standard location, too.

  • by RogueWarrior65 ( 678876 ) on Friday January 16, 2015 @10:53AM (#48830109)

    A few years ago, Inuit released an online update to Quickbooks for Mac that effed your entire partition. I happened to be away on a business trip when this happened and I had to have my backup drive FedExed to me. Did Intuit offer to pay for that? Hell no. Did anyone file a class action suit? Who knows, but even if they did, I'd have gotten discounts for coupons for cellphone cases or something equally useless.

  • man rm (Score:5, Interesting)

    by shess ( 31691 ) on Friday January 16, 2015 @10:55AM (#48830137) Homepage

    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.

    • by Z00L00K ( 682162 )

      From Fedora 20:

      --preserve-root
                                  do not remove '/' (default)

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      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

    • Re:man rm (Score:5, Informative)

      by steelfood ( 895457 ) on Friday January 16, 2015 @11:41AM (#48830693)

      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.

  • by Anonymous Coward

    I had a similar situation in a product I was working on once where it was a PHP script with an undefined variable. It was the exactly same result: rm -rf /

    Fortunately a QA guy caused it while testing. It was hell to figure out what happened because it was running as room and had wiped the entire system.

    • Re: (Score:2, Informative)

      by Anonymous Coward

      Rule #1, don't run as room. Room contains all the stuff.

  • Exception handling. No exceptions. Now go.
  • by roc97007 ( 608802 ) on Friday January 16, 2015 @11:15AM (#48830387) Journal

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

    All together now: This is why we disconnect our backup drive when we're not backing up the system!

  • This is why you should have
    set -o nounset
    set -o errexit
    at the top of every bash script. Also no one should be allowed to write a bash script unless they have read http://www.davidpashley.com/ar... [davidpashley.com]

  • When TF2 has critical bugs that are still in it after 7 years and issues like the Strange PDA Engie Upgrade Bug that has been in the product for over a year, it amazes me that these guys are still going.

    It just looks like they are running by the skin of their teeth since there are FREQUENT issues that are dangerous as hell or that stay in the product for ages.

    Every new release of TF2 seems to add new bugs and they spend more time putting in new hats than fixing outstanding issues. This reeks of shitty soft

  • This seems like a common issue in Linux, particularly for people using it as a desktop environment. What would be the preferred method to limit access? Dedicated user/group with filesystem perms, cgroups, ACLs, chrooting, security modules (AppArmor/SELinux)?
  • Is there a way to mount a disk in a "Add only no delete" mode? If not, why not?
    • by ledow ( 319597 )

      Files can be opened append only.

      This involves writes on the underlying device.

      Files can be deleted.

      This involves writes on the underlying device.

      Files can be overwritten with junk content.

      This involves writes on the underlying device.

      The underlying device has no concept of what it's actually DOING with the data it's given. That's up to the filesystem. So devices have precisely two "permissions". Read. Write.

      The safeguards should be in the filesystem, but the filesystem people will tell you "That's what

  • I bet someone is going through the blame diff's hoping they don't see their name... (2:03 https://www.youtube.com/watch?... [youtube.com])
  • $ man rm

    Where's "rm --preserve-root" when you need it?

  • I had a problem with th OS X version of steam. Client updates failed when placing the program in a different folder than applications.

  • by John Allsup ( 987 ) <slashdot&chalisque,net> on Friday January 16, 2015 @12:42PM (#48831483) Homepage Journal
    while ((c = ...
    {
        ...
    }

    /* INSERT THIS */

        if( x.interactive == RMI_NEVER && x.ignore_missing_files == true && x.recursive == true ) {
            char *mayi = getenv("RM_ALLOWRF");
            if(mayi && strcmp(mayi,"YES")) {
                printf("rm -rf allowed\n");
            } else {
                printf("rm -rf not allowed (set RM_ALOWRF=YES to enable)\n");
                exit(EXIT_FAILURE);
            }
        }

    /* END INSERT */

    if (argc <= optind)
        {
    ...
  • by janoc ( 699997 ) on Friday January 16, 2015 @01:05PM (#48831793)

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

    https://support.steampowered.c... [steampowered.com]

    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.

  • by ssam ( 2723487 ) on Friday January 16, 2015 @01:19PM (#48831975)

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

Heard that the next Space Shuttle is supposed to carry several Guernsey cows? It's gonna be the herd shot 'round the world.

Working...