Linux STEAM users...warning!

[Elixer]

http://www.pcworld.com/article/2871...erases-all-the-personal-files-on-your-pc.html

If you’re a Steam fan running Linux, the last thing you’ll want to do in the next few days is mess with your Steam files. Users on Valve’s GitHub Steam for Linux page are complaining about a nasty bug that has the potential to wipe out every single personal file on your PC. Even worse, users say the bug will even wipe out documents on USB connected drives. So much for local backups.

Ouch!
It will delete everything (rm -rf /) only if STEAMROOT is null, hope you don't run as root! 😛
This is if you uninstall something in steam.

 

[AnonymouseUser]

That's a big mistake...

 

[postmortemIA]

That's a big mistake...

The problem is that Steam linux launcher is a script that does whole bunch of stuff before running the executable.

 

[bbhaag]

If I read the article correctly it appears to only affect users who have moved the or changed the default settings for Steam.

Users complaining of this bug appear to have moved their .steam or ~/.local/share/steam directories, or invoked Steam’s Bash script with the —reset option enabled.

That's fine you're obviously allowed to do what you want with your pc but I don't think it's Valves fault. Either way though it would really suck to lose all your personal files.

 

[Elixer]

That's fine you're obviously allowed to do what you want with your pc but I don't think it's Valves fault. Either way though it would really suck to lose all your personal files.

It is Valve's fault, haven't they ever heard of error checking ?
It should have thrown up red flares the instant someone wrote "rm -rf $var/"

 

[bbhaag]

I'm sure they did error check the default installation, but once you decide to go at it alone and start tinkering with that it kinda falls back on the user....just sayin.

 

[Elixer]

It is a script though, and it is brain dead at that, and the script has 0 error checking.
It doesn't matter what the user does, the script should have checked for that variable, and NOT allow rm -rf / if the variable was null.

 

[bbhaag]

Well I guess we are just going to disagree on this then.
I'm of the opinion that if you decide to change the default script even if it is a "brain dead" one you should have the knowledge and awareness to catch things like this. If you don't then be prepared to accept the consequences of modifying the default install.

 

[Essence_of_War]

It should have thrown up red flares the instant someone wrote "rm -rf $var/"

Yeah. It's good practice to check for the existence of the path you're trying to delete to make sure that you don't accidentally evaluate do this. rm is a well known way to blow someone's leg off, I think we can all agree that it's best if you at least make sure you know what you're aiming for rather than firing indiscriminately.

 

[Red Squirrel]

Yikes, that's scary. Downside of the way the Linux file system works though, in Windows something like this would only blow away your system drive, not all your network and attached drives too. Once Linux viruses become more common it wont take much for someone to slip a rm -rf / in there. You can have all the security you want, but you WANT to be able to access your network drives and storage devices (otherwise it defeats the purpose) so no amount of permissions can fix something like this.

What that script should be doing is CDing to a known folder like /tmp or ~ and then executing it as a relative path. At least worse case scenario you blow away a temp folder or home directory and not your entire network. Checking the variable for null would also be a good idea...

 

[TheRyuu]

What that script should be doing is CDing to a known folder like /tmp or ~ and then executing it as a relative path. At least worse case scenario you blow away a temp folder or home directory and not your entire network. Checking the variable for null would also be a good idea...

I've also seen chroot being suggested as another way to mitigate this kind of problem.

I also don't see why that script needs to be running as root (does it even run as root? I'm not a (desktop) linux user), it shouldn't even have an opportunity to be able to do (rm -rf /) what it does.

 

[AnonymouseUser]

I've also seen chroot being suggested as another way to mitigate this kind of problem.

I also don't see why that script needs to be running as root (does it even run as root? I'm not a (desktop) linux user), it shouldn't even have an opportunity to be able to do (rm -rf /) what it does.

It doesn't need root, but will delete user files when run as a normal user. If run as root it will hose your system.