Slashdot Mirror
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.
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
I had a similar situation in a product I was working on once where it was a PHP script with an undefined variable. It was the exactly same result: rm -rf /
Fortunately a QA guy caused it while testing. It was hell to figure out what happened because it was running as room and had wiped the entire system.
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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...
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
From what I understand, this is how Android works. Every app gets its own user and group.
It is also, sort of, how Docker works. Each app gets its own container, the app is completely bound to that container. Docker manages access to outside resources (like the network) for you, utilizing cgroups, and kernelspace drivers.
I was hoping someone would mention Android.
Just a pity Android doesn't let you do anything meaningful with that well-designed permissions infrastructure...
For instance, you either trust an app with your entire contacts-list, or your contacts-list is out-of-bounds entirely. There no way to 'Add contact to app', and have that launch a trusted contact-selector utility.
Maybe because I don't want 300 users on my system, where each little application and widget has to add another group and user to the system. If my home directory were to contain files owned by hundreds of throwaway user accounts, I would not be happy.
This is exactly where application sandboxing comes into play. The operating system needs to be built to keep an application within proper bounds. Not only good for removing permission clutter, but also heavily improves security at the cost of the inconvenience of having to grant an application explicit permission to operate on files outside its own sandboxed file structure.