Simple Bash syntax error in Steam for Linux executed “rm -rf /*” (2015) (opens in new tab)

(github.com)

31 pointsjakejarvis7y ago12 comments

12 comments

10 comments · 3 top-level

MrMember7y ago· 4 in thread

>Line 468: rm -rf "$STEAMROOT/"*

Oh man, reading that line made me cringe.

Seriously, how do you use rm -rf anywhere in a script without copious if statements? It's quite easy to avoid this mistake.

jakejarvisOP7y ago

TIL that this quick trick [1] also would have prevented this:

  ${STEAMROOT:?}

...where :? throws an error if the variable is unset or empty. (Still far too scary for my taste, though!)

[1] https://github.com/koalaman/shellcheck/wiki/SC2115

2 more replies

xiphias27y ago

If you need an extra check in any API to do something really damaging, the problem is with the design of the API itself.

I generally just prefer not using Bash scripting, as it's very hard to compose functionality in it.

schwap7y ago

Or maybe just `set -o nounset`

smhenderson7y ago· 2 in thread

My first thought on reading the headline was "what Linux still did that in 2015"? I thought I read somewhere years ago that Sun, BSD and GNU rm all had checks in them to spot the / or /* and refuse to run. According to this SE page[1] GNU even has an option to tell rm "no I really do want to blow away my whole root" by using "--no-preserve-root".

Apparently the "fix" only applies to the root user. The article is about a regular user who recursively lost everything he owned starting at /.

Ouch!

[1] https://unix.stackexchange.com/questions/19547/how-far-can-y...

AnssiH7y ago

GNU rm only catches "/". The Steam issue was for /* which is expanded by the shell.

smhenderson7y ago

That seemed crazy to me so I spun up a VM, took a snapshot and then ran rm -rf /* as root. Sure enough it started nuking everything it could, skipping over only a few things like most of what's in proc, etc...

Thanks, it's was interesting to see the difference!

jimrandomh7y ago· 1 in thread

The real problem here is that a multi-hundred-line script was written in bash. While bugs can happen in any language, this particular error was due to a bash-specific pitfall, and bash has many such pitfalls. Bash is really only suitable for interactive use, or for bootstrapping the install of another scripting language.

klogf7y ago

I think this goes too far. There are many robust scripts out there. If you use rm -rf, change into a hardcoded directory first and then remove another explicit directory.

Recursively removing something that starts with a shell variable is stupid.

j / k navigate · click thread line to collapse

12 comments

10 comments · 3 top-level

MrMember7y ago· 4 in thread

>Line 468: rm -rf "$STEAMROOT/"*

Oh man, reading that line made me cringe.

smhenderson7y ago

Seriously, how do you use rm -rf anywhere in a script without copious if statements? It's quite easy to avoid this mistake.

jakejarvisOP7y ago

TIL that this quick trick [1] also would have prevented this:

  ${STEAMROOT:?}

...where :? throws an error if the variable is unset or empty. (Still far too scary for my taste, though!)

[1] https://github.com/koalaman/shellcheck/wiki/SC2115

2 more replies

xiphias27y ago

If you need an extra check in any API to do something really damaging, the problem is with the design of the API itself.

I generally just prefer not using Bash scripting, as it's very hard to compose functionality in it.

schwap7y ago

Or maybe just `set -o nounset`

smhenderson7y ago· 2 in thread

Apparently the "fix" only applies to the root user. The article is about a regular user who recursively lost everything he owned starting at /.

Ouch!

[1] https://unix.stackexchange.com/questions/19547/how-far-can-y...

AnssiH7y ago

GNU rm only catches "/". The Steam issue was for /* which is expanded by the shell.

smhenderson7y ago

Thanks, it's was interesting to see the difference!

jimrandomh7y ago· 1 in thread

klogf7y ago

I think this goes too far. There are many robust scripts out there. If you use rm -rf, change into a hardcoded directory first and then remove another explicit directory.

Recursively removing something that starts with a shell variable is stupid.

j / k navigate · click thread line to collapse