Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

251–260 of 280 posts

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

#251

Post by kazinator »

jzwinck wrote: post #165
kazinator wrote: post #53

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.

That one I almost always use, but it's not very relevant to this specific case. If you add it to an existing script, there is usually work to be done because up until now, the script might have been working properly only because it persisted through some failing commands.

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

#252

Post by Latty »

Chattered wrote: post #187
justizin wrote: post #57

Earlier quoted context omitted.

That is quite frustrating, and consumer vendors should be mindful of creating life-changing experiences. Also: backups. I know it sounds cliche, but look, if it has a mechanical hard drive, the manufacturer could have slightly mis-calibrated one of the mechanical assemblies, and this could have happened because the nature of digital storage is that it is essentially ephemeral. Protect yourself from things outside you…

But if that external usb drive is mounted at the time (as in the case of the user this thread is about), then all data on that drive will be deleted. For this reason, the recommened way to use things like rsnapshot is to have your backup directories owned by root and with permissions masked to something like rwxr--r--. If you then want to read your backups easily, you do things like mount it under NFS as read-only.

A (RAID6) fileserver running ZFS with filesystem-level snapshotting. It's really, really good.

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

#253

Post by SixSigma »

Chris_Newton wrote: post #51

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…

Or use a check pointed file system with off-site storage. My PC can catch fire any day and I would lose nothing.

Sure, this Steam thing sucks but your disk could die any moment; be prepared. RAID is not backup

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

#254

Post by kazinator »

drothlis wrote: post #221
oblio wrote: post #200

Earlier quoted context omitted.

I use this holy trinity in most of my scripts: set -o nounset # set -u set -o errexit # set -e set -o pipefail # I'm not sure this has a short form. I use the long forms for the option names because they're self documenting. If anyone has more suggestions, I'm all ears.

David A. Wheeler recommends setting IFS=$'\n\t' to handle spaces in filenames & variables. http://www.dwheeler.com/essays/filenames-in-shell.html

All those rules add up to: "avoiding writing anything complicated or general purpose in the shell language that is intended to be used by any user over any set of files; stick to handling known input materials which are closely associated with the script."

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

#255

Post by Karunamon »

pjc50 wrote: post #248
Karunamon wrote: post #246

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…

Steam runs content from the internet: the steam store, and all the downloaded games are from the internet. And where do your apps come from? Wasn't there a thread the other day about installing the top apps from download.com and counting the chaos they inflicted on the system? Sure, you can avoid that, but not everyone does.

Steam runs mostly upstream vetted content, i.e. it's identical to the app store. If malicious code makes it through there, everyone is varying degrees of boned, sandboxes be damned. Yeah, it has a web browser, but 99% of the time, that browser is pointed at https://something.steampowered.com.

It's not like an average browser like Chrome where your main use case is running random code from random domains made by random people.

Besides, external apps are non-responsive to the question of whether the tradeoff gained by Apple's variant of sandboxing (where there are certain things you are not ever allowed to do, even if they are integral to the primary purpose of your software) is really worth preventing a limited class of issues?

App store requirements don't stop the user from downloading malware outside of the store. They do stop the user from doing certain things outright, and so push the user outside of the store, and so I'd argue, actually reduce safety as a knock on effect.

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

#256

Post by Zancarius »

jjnoakes wrote: post #233
Zancarius wrote: post #103

Earlier quoted context omitted.

Reminds me of a shell trick I saw many years ago for short circuiting accidental 'rm -rf's by issuing a 'touch -- -i' in a sensitive location. In bash (and others), the glob operator inadvertently feeds the '-i' (now a file) into rm as an argument which then interprets it as its "interactive" flag, causing it to prompt for continued removal.

Which only helps "rm -rf ". It does nothing for "rm -rf /anything" or "rm -rf /anything/ " or "rm -rf /*" or any other way of spelling doom.

Which is why I mentioned the glob operator! Speaking of which, if you did touch '/-i', it would catch

  rm -rf /*
Ironically, I was thinking of adding that specific directories would not be caught (obviously), but I figured that would be understood implicitly since most people ought to know what actually does in the shell. And if they don't...

Edit: I just noticed that the glob operator in my first comment didn't show up, because it was eaten by markdown. Incidentally, so was the asterisk in your post! That might be the source of your confusion. In that case, I should specify such a trick only works with:

  rm -rf *
  rm -rf /*
  rm -rf ~/*
Or similar. Not specific files. But, again, I appeal to the importance of understanding what the glob operator actually does!

As an aside, the context of this post is a mistake in steam.sh which may essentially do:

  rm -rf /*
So, the discussion implicitly has nothing to do with exact paths. :)

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

#257

Post by ejdyksen »

quotemstr wrote: post #162
ejdyksen wrote: post #92

Earlier quoted context omitted.

Sandboxed applications in OS X can read/write to arbitrary locations if they use the system Open/Save dialogs to ask the user about those files (after opting into sandboxing, of course). See here [1]. For files and folders the user cares and knows about (documents, projects, etc), this shouldn't be a problem. For files the user doesn't care about (caches, configuration), you can just leave them in your sandboxed cont…

Lots of applications (like Emacs and vim) don't use the system file dialogs though. It'd be nice to preserve old-fashioned file access for them.

Well, of course, sandboxing is opt-in, and there are still lots of programs out there that don't use them.

I'm not sure Emacs or vim, as an example, would ever be able to be sandboxed from the filesystem.

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

#258

Post by perturbation »

koenigdavidmj wrote: post #42
jjnoakes wrote: post #33

Earlier quoted context omitted.

There's nothing wrong with that line as long as you know "$STEAMROOT" contains a directory that you wish to nuke. The issue is that this particular script did not set up $STEAMROOT correctly.

If you want to blow away a directory, do this just to avoid wildcard games: rm -rf $the_dir && mkdir $the_dir Yes, it's technically slower, but this is shell.

Should mkdir be first (so that it short circuits if $the_dir is unset?) I haven't done anything in bash in a while but that seems to be how it works on my computer (Debian Wheezy, bash 4.2.37).

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

#259

Post by koenigdavidmj »

perturbation wrote: post #258
koenigdavidmj wrote: post #42

Earlier quoted context omitted.

If you want to blow away a directory, do this just to avoid wildcard games: rm -rf $the_dir && mkdir $the_dir Yes, it's technically slower, but this is shell.

Should mkdir be first (so that it short circuits if $the_dir is unset?) I haven't done anything in bash in a while but that seems to be how it works on my computer (Debian Wheezy, bash 4.2.37).

The original broken code was using a wildcard to clear a directory. I proposed a safer way of doing that: delete the directory itself then recreate it.

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

#260

Post by oblio »

ufo wrote: post #239
oblio wrote: post #200

Earlier quoted context omitted.

I use this holy trinity in most of my scripts: set -o nounset # set -u set -o errexit # set -e set -o pipefail # I'm not sure this has a short form. I use the long forms for the option names because they're self documenting. If anyone has more suggestions, I'm all ears.

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

Post reply on HN