Live data from Hacker News

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

github.com

261–270 of 280 posts

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

#261

This is a danger of me-ware being used before it becomes software. Software assumes and defends against others using and running it. Me-ware makes no assumptions because me is the only one running it. The transition from meware to software is a hard one - and usually it's how we get terrible reputations as an industry. Basically it's a prototype till it's burned enough beta users. Edit OMG - that is actually Steam fr…

Though it turned out to be irrelevant, I really enjoyed your spiel about "me-ware". The distinction between it and finished software is too easy to forget.

I'm pretty sure I stole of off the guy who wrote Source Vault SCM but his name escapes me.

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

#262

Earlier quoted context omitted.

There seem to be several reasonable ways to address this kind of situation without requiring universal access. One would be analogous to an ACL arrangement rather than simple ownership. Steam applications could be installed with Steam also having permission to access their resources. A second possibility would be to have the operating system provide dedicated services for installing and maintaining software. We’re al…

Silly question; how common is this class of bug? We're talking about an application that lives on the local system, and is probably only exploitable via social engineering bugs (i.e. we convince the user to do something stupid). I can count the times I've been owned through an app that doesn't run content from the internet (either accessed by or being a server for) on zero hands. What is the problem that sandboxing e…

Silly question; how common is this class of bug? We're talking about an application that lives on the local system, and is probably only exploitable via social engineering bugs (i.e. we convince the user to do something stupid).

We live in a world where merely installing software might also install a silent updater in the background, or might interfere with existing software that it has no need to touch, or might start monitoring peripherals and phone home with data in ways that could invade privacy. We also live in a world where once popular software, particularly freely available software, sometimes drifts into borderline malware territory over time. In this world, “doing something stupid” can be as simple as turning on your computer and installing (not running, just installing) some of the most popular software in the world today on it.

What is the problem that sandboxing every app into a homogenous set of thou-shalt-not's solves?

To give a few examples, some of us would consider it a bug for everyday applications to splat junk all over a filesystem during a build/install, or to hide data in odd places as part of a copy protection scheme, or to scan a whole disk and automatically upload any files that might support “cheating” in a game to the mothership.

Unlike some here, I am not willing to trust the good intentions of a software developer just because I have paid good money to use their product. Far too many shady practices go on in parts of our industry for that to be a sensible policy without adequate safeguards in place any more.

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

#263
post #113
post #55

Earlier quoted context omitted.

But why would the script prompt for user input unless something was awry? Presumably they control the contents of $STEAMROOT, so I don't see why rm -r should prompt unless it's about to do the wrong thing.

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

Shells (at least bash) don't evaluate aliases when running non-interactively.

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

#264

Earlier quoted context omitted.

Silly question; how common is this class of bug? We're talking about an application that lives on the local system, and is probably only exploitable via social engineering bugs (i.e. we convince the user to do something stupid). I can count the times I've been owned through an app that doesn't run content from the internet (either accessed by or being a server for) on zero hands. What is the problem that sandboxing e…

Silly question; how common is this class of bug? We're talking about an application that lives on the local system, and is probably only exploitable via social engineering bugs (i.e. we convince the user to do something stupid). We live in a world where merely installing software might also install a silent updater in the background, or might interfere with existing software that it has no need to touch, or might sta…

And so the answer is to hamstring what all apps can do in the aim of safety?

...there's a commonly misattributed quote I have in mind that describes this situation.

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

#265

Earlier quoted context omitted.

lol, ok lets break this down Barney style: Converting sunlight to electricity is a solved problem. The "energy crisis" remains unsolved. Jailing processes is a solved problem. Preventing users from shooting themselves in the foot remains unsolved. Now let us reexamine the post: > ...would be a helpful thing to build into modern operating systems... Already built in. > Why can’t we also have something analogous where…

I’m well aware of strategies using chroot, virtual machines, and the like. These are useful tools up to a point, but a long way short of what I would ideally like to see. For example, they restrict access at a very coarse level compared to the kinds of user/group/ACL models we use in many other contexts. By their nature, they also do not admit convenient ways to break out of the jail with the user’s explicit consent.…

It sounds to me like your ideal situation could be implemented with the tools we already have at hand - it is just an issue of default settings and how the package maintainers set compilation and installation options. Unless you really wanna go hardcore and advocate for something that is impossible for users/developers to break, which would most likely require a formally verified microkernel [0] - at the very least.

[0] http://en.wikipedia.org/wiki/L4_microkernel_family#High_assu...

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

#266

rm -rf "$STEAMROOT/"* This is why serious bash scripts use set -u # trap uses of unset variables Won't help with deliberately blank ones, of course. Scripting languages in which all variables are defined if you so much as breathe their names are such a scourge ... I did this once in a build script. It wiped out all of /usr/lib. Of course, it was running as root! That machine was saved by a sysadmin who had a similar…

While you're at it: set -e # exit on unchecked failure That way you don't trudge forward through an untested code path after a failure, you stop there and then.

Beware, this doesn't always work. For instance, inside a function called by a pipeline that is part of an if condition.

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

#267
post #43

Note to all, prepend all your bash script with "set -o errexit -o nounset -o pipefail" It'll save you headaches.

I use the shebang "#!/bin/bash -e". To get the same effect as the "set -o errexit -o nounset", I think you can use "#!/bin/bash -e -u". (There seems to be no option for pipefail.)

This breaks if your script is sourced by another shell. Best use 'set -eu' at the start instead.

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

#268
post #260
post #239

Earlier quoted context omitted.

Are these bash-exclusive or do they also work on posix-like sh?

I doubt it. set -e is POSIX, I think, but the rest are probably bash extensions. I'll probably get flak for this, but for 99% of the scripts, at this point I'd just use bash. Linux has it as a default, as does Mac OS, anyone running BSDs can install it trivially, and Unixes probably have it as well since most of them have antiquated CLI environments and administrators usually install GNU utils to have a more human wo…

See here:

http://pubs.opengroup.org/onlinepubs/009695399/utilities/set...

"-u The shell shall write a message to standard error when it tries to expand a variable that is not set and immediately exit. An interactive shell shall not exit."

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

#269
post #98

Earlier quoted context omitted.

> Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avionics bugs, and people lose fortunes -- or welfare checks -- because of finance programming errors, but programmers just throw up their hands, and say that programming is hard. Yeah, we've all noticed the rampant mass deaths of millions…

So you're telling us that accidental death is okay as long as it isn't in the millions? How did you decide on that number? Where is the line drawn?

>So you're telling us that accidental death is okay as long as it isn't in the millions?

Yes, of course. We take such decisions everyday. Cars lead to deaths from traffic accidents, and still we are ok with it as a necessary evil, since we want the benefits they provide.

If we restricted technology to "things that can cause absolutely no deaths" we would even have used fire (tons of people die every year from it). Heck, houses too can collapse in an earthquake etc -- we should make sure noone builds one until its 100% safe house (that costs some millions to build).

But my sarcasm was directed at the parent blowing this "deaths due to software" thing out of proportion, and making it sound like someone dies every minute from a buffer overflow.

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

#270
Reminds me of a bug with the Myth II uninstaller immortalized by the following Penny Arcade cartoon:

http://www.penny-arcade.com/comic/1999/01/06

Basically, they called delete tree. If the user installed or moved the game to a different location, say, the root, it would delete tree away somebody's whole computer. Fun times.

Post reply on HN