Live data from Hacker News

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

github.com

121–130 of 280 posts

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#121
post #12

A while ago I made a small program to cache Steam's grid images and search missing ones ( https://github.com/boppreh/steamgrid ). More of an experiment in programming in Go, really, but it works and makes Steam a little better. When I tried on Linux, it threw a permission error. Turns out Steam installs the folder "~/.local/share/Steam/userdata/[userid]/config/grid" without the executable permission bit. Without this…

Vavle's customer support is known to be pretty awful. This is all too familiar an issue.

To be fair to them, when the six-sigma of your customer service is 15 year olds asking to be unbanned cause they totally didn't use hacks, your CS probably gets a bit desensitised.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#122
post #96

Why are we still running bash scripts? The only thing worse might be DOS batch files. It's not like python isn't available on every major linux distro. It's a little harder to ensure it's on windows, but when Steam is installing every point release of the Visual C++ runtime that has ever existed on my system, why not bundle python in there too?

> Why are we still running bash scripts?

Because admins gotta admin. Also, adding python to a software suite just to work on the file system... gross.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#123
post #11

I don't want to blame anyone, but maybe there should be foolproof default security measures that prevent something like this from happening. For example rm -rf called on a home, documents, music, photos etc. directory could require an additional confirmation, perhaps through a GUI.

There are, it's called users, and groups, and file permissions. Applications like steam should really be running under a separate user so they can't write to personal files (and maybe just have read permissions). But of course proper application isolation and file permissions is something few people do correctly on their personal machines, let alone know about. Window managers don't make it any easier, and I put a lo…

Steam shouldn't run as its own user. It's a user-level process, not a system process. It needs to have user-specific things (install directory, save games, etc.) that need to be accessible to the person using it. Separating processes into users is only one method of sandboxing, and not appropriate in this case. Sandboxing via mechanisms like SELinux is the correct solution.

One of the users in the Github thread even mentions how SELinux prevented the same thing from happening on his machine.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#124

To those name-calling the author of the script: The product/update is hyped and the release date is set in stone. Tensions are high and your boss has already let you know that you're on thin ice and not delivering on the project goals. A last-minute showstopper bug comes in, caused by file leaks. Everyone is scrambling, and the file belongs to you so its on you to fix it alone. There is no time for code review, and d…

but the same wouldnt be acceptable in other lines of work right? Try a civil engineer or surgeon... what would you expect someone to do in similar situations? Probably escalate the issue and perhaps delay the release.

Pushing in shitty broken means you're not doing your job. If your company forces you to do this then they are not doing their job.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#125

Earlier quoted context omitted.

Isn't this the basic idea behind the sandbox in OS X? I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address. First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broade…

Is it really a net improvement? There are a number of developers out there that have pulled out of the app store (off the top of my head, Atlassian for SourceTree, and Panic for Transmit) because the sandbox restrictions would force them to remove functionality from their applications. As far as Apple's implementation goes, sandboxes are for kids, not adults that need to get work done.

SourceTree and Transmit need to stomp all over directories to get things done. Yes, it's useful. But it's not common for applications to need that kind of access. The sandbox seems to work fine for the other 99% of applications. I think Apple even uses the sandbox heavily for their own apps, check ~/Library/Containers next time you use an OS X system.

The only complaint here is about the app store, sandboxing is wonderful.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#126
post #120
post #113

Earlier quoted context omitted.

most systems have "alias rm='rm -i'" by default, so it would prompt on every single file regardless of ownership, etc.

"most systems"? Not on Debian or Ubuntu, and that's most of them.

fwiw, making those "-i" aliases to rm, mv and cp are one of the first things I do on any new Linux machine I'm on.

I don't understand how anyone works in the very unforgiving-of-accidental-delete *nix world without those aliases.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#127

This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data withou…

You are describing a problem that has been solved several times over. Blame steam, the distro devs, or the user for not implementing one of the many long existing solutions: chroot [0]. [0] http://en.wikipedia.org/wiki/Chroot

If a problem has been solved several times over, that's a sign that it has never really been solved. If there's a thing that most apps should do, then doing it should be the default, and avoiding the default should be the thing that takes work.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#128
post #96

Why are we still running bash scripts? The only thing worse might be DOS batch files. It's not like python isn't available on every major linux distro. It's a little harder to ensure it's on windows, but when Steam is installing every point release of the Visual C++ runtime that has ever existed on my system, why not bundle python in there too?

And even if it isn't, modern perl would do as well as python for this case, with no language wars required.

Re: Moved ~/.local/share/steam. Ran steam. It deleted everything owned by user

#129
post #3

Here's the offending shell script code: # 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)" [...] # Scary! rm -rf "$STEAMROOT/"* The programmer knew the danger and di…

Yikes. That should never have passed a code review. I know mistakes happen, I often defend screw-ups, but anything in a shell script that has an "rm" command should automatically get the squinty eyes.

Also, someone should have been asking "Why is that scary?" - which should have lead to a discussion on alternatives.
Post reply on HN