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.
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!
Is why you have backups. You need to apply the rule Total Backups = Total Backups -1 so if you have 1 you have 0.
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.
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.
Wow! That is all.
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.
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.
Who cares about root! My home directory is WAY more important than the system.
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).
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.
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.
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.
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.
You could also do what I did once, and accidentally hit space in the command and not notice.
rm -rf a/bunch/of/local/junk /
Except that's not quite right. What I actually did was:
sudo rm -rf /usr/local/dontremember /bin
You are in a maze of twisty little relative jumps, all alike.
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.
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.
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.
> 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!
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
rm -rf .*
The key fact is that .. matches .*
Rule #1, don't run as room. Room contains all the stuff.
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)
{
...
John_Chalisque
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
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.
And yet some people still cling on to shell scripts for their boot system.
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
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.
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.
The better system is called capabilities. Think "everything is a file descriptor". You want to create a file, you get a file descriptor. You want to run most programs, you give them read-write scratch space, a place to find common library routines (that don't carry any rights by themselves), and probably a read-write access to some graphical interface window. You're a browser, your user clicks on a java applet? You download the applet into a descriptor from your scratch space, you run it, giving it a read-write descriptor to some user interface sub-window created from your own window, read-write to a descriptor of some scratch space created from you scratch space, and read-execute of some descriptor containing a library, probably the same one you got from your parent. You have a video with a proprietary codec? You run the proprietary program as above with read-only to the video. You're a word processor? You get a RW descriptor to the file you're editing, and a call-back to your parent if your user requests an "open file" dialog, which returns a RW (or maybe RO) descriptor to the file the user indicated. See a pattern? See KeyKOS, which actually worked for years, and followers EROS, CapROS, Coyotos, which none got to to any useful status. There was a guy who rewrote libc on these principles, IIUC so that you'd only have to change file-handling logic in classical programs and recompile. But I get the impression that most people working on these things are security and OS researchers in academia (sincerely sorry if someone feels insulted, I'm not helping out and if you weren't working on it I wouldn't even know about these things), and not people saying OK, I have a generous budget, I have excellent developers and excellent team leads and stellar project managers, now I want a timeline and then a product.
For other non-OS projects see Plash, Capsicum, Tahoe-LAFS, E-Lang, CapDesk...