6 ms·

Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*

by kevan 12y ago

deleted 12y ago
[deleted]
a13xb 12y ago
I feel like it would be a frighteningly common bug. I remember one like this from 2011 [1]. Install/packaging/utility scripts usually do not get as much attention and testing as the application code itself. [1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...
- userbinator 12y ago
  I'd say the fact that these bugs only very occasionally happen - relative to the huge number of shell scripts out there that are being executed every day - that it's not really "frighteningly common". You only hear about the ones that fail.
  - MichaelGG 12y ago
    By the same logic, memory safety issues only happen rarely, right? Most programs/scripts are going to be tested if part of a distribution and such errors removed. But without polling people it'd be hard to know of the many times this kinda thing messed things up. I personally wiped out a production DB due to expanding an unset variable (fortunately immediately after taking a backup.
DSMan195276 12y ago
That's not completely true. At least with the GNU tools, 'rm' won't delete the root directory unless you specifically give it the '--no-preserve-root' flag. Since that flag has no use outside of deleting root, it's unlikely it has the flag on it. With that in mind the script must do some type of manual deleting for some reason.
- viraptor 12y ago
  I believe that "--preserve-root" applies only to / itself. That means `rm -rf /*` will expand to `rm -rf /bin /dev /etc /lib ...` and delete all anyway.
  - DSMan195276 12y ago
    That's accurate. `rm -rf /* ` will still work to delete everything. But that said, `rm -rf "$STREAMROOT/"` can't ever expand to that, and more-over since the expansions in double-quotes it won't be subject to path expansion by bash. So even "/* /", which would normally expand into "/bin/ /dev/ /etc/ ..." won't. You can see what I mean yourself, just use echo: `echo /* `: /bin /dev /etc /lib ... `echo /*/`: /bin/ /dev/ /etc/ /lib/ ... `echo "/*"`: /* `echo "/*/"`: /*/ If you try it with `ls`, you'll find that `ls "/* "` results in `ls: "/* ": no such file or directory`. Edit: Formatting.
    - pskocik 12y ago
      The original example was `rm -rf "$STREAMROOT/"*`, though (the asterisk being out of the double quotes.) Now that glob will expand.
      - DSMan195276 12y ago
        Ah, my apologies, I think that was HackerNew's markup at work. The '* ' wasn't there when I looked before.
  - mirkules 12y ago
    This just happened to my coworker today. I'm sitting behind him telling him which commands to type (he's new to Linux...) when suddenly he jumps the gun and pushes enter just as I say "slash". My heart nearly stopped. I didn't even know preserve-root existed (plus I always iterate not to log in as root). It was a snapshotted vm but we still would have lost the day's work.
    - deleted 12y ago
lpsz 12y ago
And this is why it is important to write something like set -eu on top of your bash scripts -- execution will stop on errors (non-zero retvals) and on undefined variables.
- guardian5x 12y ago
  I wonder why set -eu is not the default setting.
  - anh79 12y ago
    set -u is good. set -e requires to change a lot of code. See for example https://github.com/icy/bash-coding-style#set--e https://github.com/icy/bash-coding-style#set--e
  - blueskin_ 12y ago
    1. open bash 2. set -e 3. type an invalid command or run one that returns non-zero 4. "crap, where did my shell go?"
    - twic 12y ago
      It could be the default for non-interactive shells without causing this problem. Or we could have a more nuanced rule, where -e means "stop executing the current sequence of commands as soon as there is an error", where a "sequence of commands" is a single line in an interactive shell (so "false; whoami" would print nothing), or the entire file in a script. The real answer is that this has not been the default in the time between shells being invented and this comment being posted, and so the squillions of lines of shell script out there in the wild keeping the world turning have not been written with this in mind. Making it the default now would break a lot of things. With the benefit of hindsight, though, i would say that yes, this should have been the default in scripts. Oh well.
      - jamiesonbecker 12y ago
        There are lots and lots of these 'nuanced rules'. http://mywiki.wooledge.org/BashFAQ/105 http://mywiki.wooledge.org/BashFAQ/105

Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*

by kevan 12y ago

Agreed, I should've elaborated. All it takes is something like this in the init script without checking if the variable is empty: rm -rf "$STEAMROOT/"*

deleted 12y ago

[deleted]

a13xb 12y ago

I feel like it would be a frighteningly common bug. I remember one like this from 2011 [1]. Install/packaging/utility scripts usually do not get as much attention and testing as the application code itself. [1] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123 https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issue...

userbinator 12y ago
I'd say the fact that these bugs only very occasionally happen - relative to the huge number of shell scripts out there that are being executed every day - that it's not really "frighteningly common". You only hear about the ones that fail.
- MichaelGG 12y ago
  By the same logic, memory safety issues only happen rarely, right? Most programs/scripts are going to be tested if part of a distribution and such errors removed. But without polling people it'd be hard to know of the many times this kinda thing messed things up. I personally wiped out a production DB due to expanding an unset variable (fortunately immediately after taking a backup.

DSMan195276 12y ago

That's not completely true. At least with the GNU tools, 'rm' won't delete the root directory unless you specifically give it the '--no-preserve-root' flag. Since that flag has no use outside of deleting root, it's unlikely it has the flag on it. With that in mind the script must do some type of manual deleting for some reason.

viraptor 12y ago
I believe that "--preserve-root" applies only to / itself. That means `rm -rf /*` will expand to `rm -rf /bin /dev /etc /lib ...` and delete all anyway.
- DSMan195276 12y ago
  That's accurate. `rm -rf /* ` will still work to delete everything. But that said, `rm -rf "$STREAMROOT/"` can't ever expand to that, and more-over since the expansions in double-quotes it won't be subject to path expansion by bash. So even "/* /", which would normally expand into "/bin/ /dev/ /etc/ ..." won't. You can see what I mean yourself, just use echo: `echo /* `: /bin /dev /etc /lib ... `echo /*/`: /bin/ /dev/ /etc/ /lib/ ... `echo "/*"`: /* `echo "/*/"`: /*/ If you try it with `ls`, you'll find that `ls "/* "` results in `ls: "/* ": no such file or directory`. Edit: Formatting.
  - pskocik 12y ago
    The original example was `rm -rf "$STREAMROOT/"*`, though (the asterisk being out of the double quotes.) Now that glob will expand.
    - DSMan195276 12y ago
      Ah, my apologies, I think that was HackerNew's markup at work. The '* ' wasn't there when I looked before.
- mirkules 12y ago
  This just happened to my coworker today. I'm sitting behind him telling him which commands to type (he's new to Linux...) when suddenly he jumps the gun and pushes enter just as I say "slash". My heart nearly stopped. I didn't even know preserve-root existed (plus I always iterate not to log in as root). It was a snapshotted vm but we still would have lost the day's work.
  - deleted 12y ago

lpsz 12y ago

And this is why it is important to write something like set -eu on top of your bash scripts -- execution will stop on errors (non-zero retvals) and on undefined variables.

guardian5x 12y ago
I wonder why set -eu is not the default setting.
- anh79 12y ago
  set -u is good. set -e requires to change a lot of code. See for example https://github.com/icy/bash-coding-style#set--e https://github.com/icy/bash-coding-style#set--e
- blueskin_ 12y ago
  1. open bash 2. set -e 3. type an invalid command or run one that returns non-zero 4. "crap, where did my shell go?"
  - twic 12y ago
    It could be the default for non-interactive shells without causing this problem. Or we could have a more nuanced rule, where -e means "stop executing the current sequence of commands as soon as there is an error", where a "sequence of commands" is a single line in an interactive shell (so "false; whoami" would print nothing), or the entire file in a script. The real answer is that this has not been the default in the time between shells being invented and this comment being posted, and so the squillions of lines of shell script out there in the wild keeping the world turning have not been written with this in mind. Making it the default now would break a lot of things. With the benefit of hindsight, though, i would say that yes, this should have been the default in scripts. Oh well.
    - jamiesonbecker 12y ago
      There are lots and lots of these 'nuanced rules'. http://mywiki.wooledge.org/BashFAQ/105 http://mywiki.wooledge.org/BashFAQ/105