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.

Comments

Re:And that people...

[mwvdlee]

It is. It just protects against fewer problems.

Every type of backup method has drawbacks and benefits.
If there existed a perfect backup method, we would have only that method.

Redundancy makes it very easy and fast to recover data, but lacks security against localized physical problems and malicious software. It would be a perfectly valid first layer of backup and sufficient for backing up reproducable information such as downloaded/scanned/ripped media. It protects against accidentally deleting files or hardware problems. For less easily reproducable information you probably want some additional backup layers.

man rm

[shess]

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.

Re:When I see that [literaly] textbook mistake....

[Trepidity]

Does show a longstanding problem with the Unix security model, though: nothing more fine-grained than per-user permissions. There's no reason Steam should be able to delete (or even read) anything in my home directory other than its own files, but the only real way to keep it from doing so using straight Unix permissions is to create a new local user for every application.

Re: When I see that [literaly] textbook mistake...

[Trepidity]

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...