protonscr

Someones internal drive and external backup drive got deleted by steam on linux

steamclosed
ValveSoftware/steam-for-linux#12199 · opened 2025-07-13 by cgkjdfyfrebiqur3y · updated 2025-07-18 · 3 comments · github
Ccgkjdfyfrebiqur3y 2025-07-13 github

🐛 Critical Bug: rm -rf 'in Steam Cleanup Script Can Wipe Entire System or External Drives
Summary:

Steam for Linux still contains or previously contained logic that performs an unguarded rm -rf basis on the $STEAMROOTvariable. Under certain conditions — especially when $STEAMROOT is misconfigured, unset, or points to an unsafe symlink — this logic can result in catastrophic, irreversible data loss , including:

Deletion of the entire root filesystem ( /)

Deletion of mounted external drives , including /media/*paths

Loss of personal data, applications, backups, etc.

This is not theoretical. Users have reported real-world system wipes.

Steps to Reproduce:

Install Steam for Linux.

Create a symlink like:

ln -s / steam

Let Steam attempt to clean the $STEAMROOT .

Script runs something like:

rm -rf "$STEAMROOT"/*

If $STEAMROOT= / , or resolves to / , you've lost everything .

Expected Behavior:

Steam should never run a destructive command like rm -rf on user-defined or environment-based paths without:

Proper sanity checks

Absolute path whitelisting

User confirmation for anything outside a sandbox

Actual Behavior:

Steam cleanup scripts use rm -rf unsafely.

Symlinks or unset variables can silently redirect the deletion path.

There are no guardrails , no dry-run, and no root path protection.

Why This Is Unacceptable:

This kind of unsafe scripting is something you'd expect from malware, not from a production-grade software distributed by a major platform like Valve.

The bug was reported years ago and has caused real harm.

The fact that such a basic safeguard (eg, " if [ "$STEAMROOT" != "/" ] ") wasn't added shows a disregard for Linux safety and system hygiene.

Suggested Fix:

Never allow rm -rf operations without full path validation.

Block all deletion if the resolved path is /, /home, /media, or similar.

Explicitly prevent operation on symlinked $STEAMROOT values.

Implement a dry-run mode and prompt the user before deletion.

Consider sandboxing cleanup steps to avoid touching anything outside the Steam directory.

References:

[GitHub Issue #3671 (Archived)](https://github.com/ValveSoftware/steam-for-linux/issues/3671)

[Archived user reports of data loss]

Blog posts and forensic write-ups

Severity:critical
This is a data-destroying bug that could affect any Linux user, especially those with Steam folders on symlinked drives or unconventional setups. It must be addressed with urgency and transparency.

Ttmarques 2025-07-15 github

Steam does not run as root and cannot delete the root filesystem. If you are doing this, you are risking something bad like this.
AFAIK, if there is an issue it can delete the user's home folder, not '/home'.

Steam will get it's path from the directory where 'steam.sh' is:

STEAMROOT="$(cd "$(dirname "$0")" && echo $PWD)"
if [ -z "${STEAMROOT}" ]; then
        log $"Couldn't find Steam root directory from "$0", aborting!"
        exit 1
fi

I cannot see how what you propose will fix anything, as it is likely the bug is elsewhere.

If this is an issue, please set up a separate user for a gaming folder. Run 'steam' there, piping the output to some file in '/tmp':

steam > /tmp/steam_log.txt (Or steam.sh, I usually run the executable only.)

Then you can get this log file later.

Linux handles seat/session transitions quite well and you should do this until the problem is diagnosed or fixed.

OOhaDerErste 2025-07-16 github

This issue has been fixed 10+ Years ago.
https://store.steampowered.com/oldnews/15512

MManagor 2025-07-18 github

This seems to be AI generated.