Slashdot Mirror
Steam For Linux Bug Wipes Out All of a User's Files
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.
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...
You don't even need to check $STEAMROOT, I mean what could possibly go wrong... /* is how a Windows developer would write the command to delete a directory if they simply looked up the equivalent command for Linux.
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
Violence is the last refuge of the incompetent. Polar Scope Align for iOS
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.
It can't erase backups. Backups are offline. He imagined that an attached hard drive was backup. It is not.
Something like this might have helped:
if [ "$STEAMROOT" != "" -a "$STEAMROOT" != "/" ] ...do your evil deletion of $STEAMROOT here
then
if [ -d "$STEAMROOT" ]
then
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).
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!
Root? No. It deleted his home folder. Don't need root for that. Any user can raze their own home folder.
cat sig >
Rule #1, don't run as room. Room contains all the stuff.
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."
It also deleted everything on his mounted external hard drive.
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.