Moved ~/.local/share/steam. Ran steam. It deleted everything on system owned by user.

GitHub issue: valvesoftware/steam-for-linux#3671 Opened by user keyvin on 2015-01-14. Closed.

Original issue report

Edit: Please stop posting stupid image memes or unhelpful messages. This interferes with Valve’s ability to sift through the noise and see if anyone can figure out what triggers it.

This may not be a common problem because I change all sorts of configuration about my system. The script in question does something in a really, really stupid way, but it probably doesn’t trigger the fail scenario for every system because…

Original Bug: I am not sure what happened. I moved the folder in the title to a drive mounted under /media/user/BLAH and symlinked /home/user/.local/steam to the new location.

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.

Everything important, for the most part, was in the cloud. It is a huge hassle, but it is not a disaster. If there is the chance that moving your steam folder can result in recursively deleting everything in the directory tree you should probably just throw up an error instead of trying to point to other stuff. Or you know, allow the user to pick an install directory initially like on windows.

My system is ubuntu 14.04, and the drive I moved it to was ntfs if its worth anything.

Key comments from the thread

doofy: I am impressed how calm you stay about this. This is terrible. I just lost my home directory. All i did was start steam.sh with STEAM_DEBUG=1. I will investigate this and report back.

edit1: I suspect steam.sh got some bugs(does not check own variables) and when it tried to do scary things it crapped himself. Line 468: rm -rf "$STEAMROOT/"*

edit2: It gets better. Seems on windows Steam is overeager too! (The warning part is interesting. Because everybody reads this before uninstalling…)

CamilleScholtz: This also happened to me a few weeks ago, my entire home was deleted by the steam.sh script.

pythoneer: introduced here Sep 10, 2013 https://github.com/indrora/steam_latest/commit/21cc14158c171f5912b04b83abf41205eb804b3 line 359

rm -rf "$STEAMROOT/"* could be evaluated as rm -rf "/"* if $STEAMROOT is empty

but what exactly caused this? i’ve symlinked ~/.local/share/steam to, so i am a bit afraid to start steam :/

TcM1911: pythoneer,

I believe the issue starts on line 19:

# figure out the absolute path to the script being run a bit
# non-obvious, the ${0%/*} pulls the path out of $0, cd's into the
# specified directory, then uses $PWD to figure out where that
# directory lives - and all this in a subshell, so we don't affect
# $PWD

STEAMROOT="$(cd "${0%/*}" && echo $PWD)"
STEAMDATA="$STEAMROOT"

This probably returns as empty which mean: rm -rf "$STEAMROOT/"* is the same ass rm -rf "/"*.

jthill: Yeah, they kinda need a readlink in there.

STEAMROOT=$(readlink -nf "${0%/*}")

indrora: Can confirm; I have Steam bounded in an SELinux context (“Steam”) and SELinux spits out:

Context violation: process /home/indrora/.local/share/Steam/ubuntu12_32/steam is only allowed in context steam_context, attempted to remove /boot/efi/grub/efistub

Ooops. I’ll write a patch and PR it.

johnv-valve (Valve contributor): Does anybody have reliable repro steps for this? I can easily add the checks for STEAMROOT being empty, but I would also like to fix the root cause if possible.

rcxdude: It will definitely fail if you run steam.sh as bash steam.sh. I don’t know if that’s the cause in this case. In terms of root cause, I would say you should use set -e, set -u, and similar options in order to make the script less likely to silently ignore errors.

ayust: Using ${STEAMROOT:?} instead of $STEAMROOT would have helped, too.

(For those not familiar, ${FOO:?} is identical to $FOO except that it errors out automatically if $FOO is empty or unset.)

johnv-valve (Valve contributor), later in the thread: We shipped a one-line fix to avoid the one situation where we could reproduce the problem. We are still working on some more comprehensive changes, but we wanted to get a fix out there quickly in case this somehow hit anybody else.

If anybody knows how to actually reproduce this bug, please post the steps here or email me directly. So far we have not been able toe reproduce it and I would hate to be barking up the wrong tree if the problem is really somewhere else.

Also, I’d appreciate it if people would not use this bug report as a general discussion and debate forum. I don’t want to lock the thread, but it is pretty hard to separate out the noise at this point. Thanks!

mwestphal: it is already fixed. http://store.steampowered.com/news/15512/

MrSchism (Valve member), quoting johnv-valve: This potentially only a partial fix; discussion has been moved to the Steam forums. There the community can discuss and review the “one-line fix” and see if any suggestions can be offered.

aaronfranke: Has this issue not been fixed yet? If it has been fixed, it should be closed. If it is not fixed, it needs more attention.

kisak-valve (Valve member): Yes, the issue that is tracked in this issue report was resolved.

craig-sanders: kisak-valve said that this is resolved. It’s not, the “fix” doesn’t do anywhere near enough sanity checking for a script that has the potential to delete the user’s files.

Here’s what I consider to be the absolute minimum level of sanity checking required:

(This script was written by me and is hereby placed in the public domain, or the 2-clause BSD license if you are in a jurisdiction that does not acknowledge “public domain”. Do whatever you want with it, no royalties or any form of compensation or acknowledgement is expected or required, even the BSD license requirement to include a copyright notice is waived. I renounce all rights to this trivial code)

$ cat /tmp/steamhome.sh
#!/bin/bash

# Example of a minimal fix for:
# https://github.com/valvesoftware/steam-for-linux/issues/3671

kisak-valve (Valve member): I’d rather not lock issue reports if I don’t need to. At this point, I’d need either a test case that causes this issue or a request from a Steam dev to re-open this issue.

Since there is over a hundred participants on this issue report, I’d like to see at least 25 thumbs up on @simi’s request to lock this issue.

nicklleite (years later): Its still happening. It deleted almost everything on my Ubuntu.

kisak-valve (Valve member), final comment: Hello @nicklleite, the investigation of the issue in this issue report concluded several years ago. Please open a new issue report.

Root cause summary (as established by the community and Valve)

The steam.sh launcher script computed STEAMROOT via STEAMROOT="$(cd "${0%/*}" && echo $PWD)". Under certain conditions (e.g. running the script via bash steam.sh, or after the user relocated/symlinked their Steam directory), this computation could return an empty string. The script’s reset_steam() function then executed rm -rf "$STEAMROOT/"*, which, with an empty STEAMROOT, was equivalent to rm -rf "/"* — recursively deleting the invoking user’s files starting from the filesystem root (subject to permissions), including mounted external drives. Valve shipped a quick one-line fix to guard against the reproducible trigger case, while community members argued more comprehensive input validation (e.g. ${STEAMROOT:?}, set -u, readlink -nf) was still warranted.