Major Steam bug deletes all user files from hdd

[gamerk2]

http://www.extremetech.com/extreme/197686-nasty-steam-for-linux-bug-can-wipe-all-your-user-files

Here?s the problem: When Steam installs itself, it sets its own active directory to $STEAMROOT. If the user then moves the Steam directory, when the system attempts to run ?rm -rf ?$STEAMROOT/?*. This command tells the system to remove all subfolders and directories from STEAMROOT, including the STEAMROOT directory itself.

When that command fails to execute, typically because the end-user has moved the install directory to a different drive, the system interprets this failing as ?rm -rf ?/?. For those of you not familiar with the Bash script, that command means ?Delete everything on the hard drive.? Since Linux doesn?t give the userspace permission to touch core operating system files, the only thing that gets dumped is all the data in user-land. The command shouldn?t touch files on alternate hard drives, but since most user data is stored on the OS disk, the damage is enough to care about.

Whoops.

[Kano]

Well, something similar happenend when it tried to debug the script with sh (dash), but it is full of bashisms. It erased my home within seconds (ssd), well I could recover some data with extundelete. The startscript is completely unsafe written.

[Zan Lynx]

http://www.extremetech.com/extreme/1...our-user-files



Whoops.

Hehe. Redhat's RPM packaging tool had similar problems with RPM_BUILD_ROOT. A ton of packaging scripts would start off by doing rm -rf $RPM_BUILD_ROOT. And SOME of them put a slash on the end to make rm -rf $RPM_BUILD_ROOT/

Guess what would happen if that environment variable was somehow not set. Or was set to /

That's why the first line in the package section is now [ $RPM_BUILD_ROOT != "/" ] && rm -rf $RPM_BUILD_ROOT

Every shell scripter learns this the hard way sometime, I think.

[Kano]

Well I told myself not to debug that script again, maybe with a complete backup and without any other partitions mounted. Of course it is easy to add a little check before critical commands are executed. But what really annoys me are bashisms for no reason. Without those the var would not have been unset...

[nanonyme]

Hehe. Redhat's RPM packaging tool had similar problems with RPM_BUILD_ROOT. A ton of packaging scripts would start off by doing rm -rf $RPM_BUILD_ROOT. And SOME of them put a slash on the end to make rm -rf $RPM_BUILD_ROOT/

Guess what would happen if that environment variable was somehow not set. Or was set to /

That's why the first line in the package section is now [ $RPM_BUILD_ROOT != "/" ] && rm -rf $RPM_BUILD_ROOT

Every shell scripter learns this the hard way sometime, I think.

This may also be on of the reasons why mock (easy RPM building in a chroot) was made years ago.

[curaga]

Was anyone surprised? Steam, Origin, Uplay are malware on that other OS as well.

[nanonyme]

Also it's not as if modern rm wouldn't require an extra switch before accepting recursive removal on root. That bug has zero impact on any recent GNU/Linux

[Kano]

Wrong, often there is an alias set for "rm" as "rm -i" (just run "alias"), but in a script the defined alias is never used.

[curaga]

Kano, current GNU rm will not let you "rm -rf /". It's special-cased.

[Luke]

Yet another reason to always have offline backups

http://www.extremetech.com/extreme/1...our-user-files



Whoops.

In the world of computers, there will always be bugs. Some of them, such as kernel bugs, will corrupt filesystems. Others can erase files when
something happens the programmer didn't think about. Other comments say this time around it was a bashism in a script, triggering removal
of the home directory if the steamroot directory was moved. This bug will be squashed, others will appear.

In other words, you should regard any data that exists on only one device-or which exists only on devices that are always online together, as
not existing except in RAM until it has been backed up to another device. Also, make sure that device spends most of its time offline or is
another system. Whenever all devices containing a file are online together, a power surge or a bug could damage, hide, or even destroy
(in flash devices) all copies of the data.