41–50 of 179 posts
We had one of these kinda bugs. If you uninstalled our software it deleted a major chunk of your Windows registry, crippling your computer. It was a one character error in our script. The first ticket read "Uninstalling [Product] destroys your computer". I was responsible for customer support. Good times! Was a rough week. We managed to not get sued.
Earlier quoted context omitted.
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.
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…
We had one of these kinda bugs. If you uninstalled our software it deleted a major chunk of your Windows registry, crippling your computer. It was a one character error in our script. The first ticket read "Uninstalling [Product] destroys your computer". I was responsible for customer support. Good times! Was a rough week. We managed to not get sued.
Pretty terrible that such a thing is even allowed by Windows. This is why as a user I like Apple's OS X sandbox.
Scary. Even more scary is the fact that the bug has been open for a week, one person has confirmed 100% reproducibility, and no one seems to care at Red Hat. Isn't deleting peoples hard drives a big no no ?
Ahh Redhat, the distro which chose to symlink a bunch of binary lib files from Apache into the etc directory. "Why is grepping /etc taking so long? Binary files in /etc?!? WTF?!?" Coming from Debian, Redhat seems to make a lot of irk-worthy choices.
Hmm, there are two possible candidates in the init.d script for the RHEL 6 package of an older version of squid (doesn't look like bug submitter is using a current version). In stop(): rm -rf $SQUID_PIDFILE_DIR/* and in restart(): rm -rf $SQUID_PIDFILE_DIR/* SQUID_PIDFILE_DIR is hardcoded to "/var/run/squid" at the top of my copy of the init script. But, neither of those rm commands check first to make sure that SQUI…
squid-3.1.10-29.el6.src.rpm (from ftp.redhat.com, buried where they keep SRPMs) has squid.init within, and that file has no mention of SQUID_PIDFILE_DIR. A few other spot-checked versions are the same way. https://github.com/mozilla-services/squid-rpm/blob/master/SO... ... however ... whatever that is, does. Did they take this upstream init script somehow?
https://bugzilla.redhat.com/show_bug.cgi?id=1102343
I guess they applied that change which was obviously written against a very different init script where the variable is actually defined, got QA to test it and immediately backed it out.
Earlier quoted context omitted.
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.
or check the variable before using it, like any other programming language: [[ "$VAR" ]] && rm -rf "$VAR/*" I think most of these issues stem from the fact that most developers that write shell scripts don't actually understand what they're doing, treating the script as a necessary annoyance rather than a component of the software.
Anyways, that is not anything like other programming languages. Checking in that way is error prone and not really an improvement (nor equivalent to set -o).
[[ "$DAEMON_PATH" ]] && rm -rf "$DEAMON_PATH/*"
In other programming languages, if an identifier is mis-typed things will blow up. E.g., in ruby if I write:
daemon_path=1; if daemon_path; puts deamon_path; end
These issues do not always stem from bad developers. Bash's defaults are not safe in many ways and saying "people should just check the variable" isn't helpful here.
touch /-@
touch ~/-@
When accidentally running rm -f *, the command expands to -@ first, which is not a valid option and makes the command fail before doing any harm
rm: illegal option -- @
usage: rm [-f | -i] [-dPRrvW] file ...Hmm, there are two possible candidates in the init.d script for the RHEL 6 package of an older version of squid (doesn't look like bug submitter is using a current version). In stop(): rm -rf $SQUID_PIDFILE_DIR/* and in restart(): rm -rf $SQUID_PIDFILE_DIR/* SQUID_PIDFILE_DIR is hardcoded to "/var/run/squid" at the top of my copy of the init script. But, neither of those rm commands check first to make sure that SQUI…
squid-3.1.10-29.el6.src.rpm (from ftp.redhat.com, buried where they keep SRPMs) has squid.init within, and that file has no mention of SQUID_PIDFILE_DIR. A few other spot-checked versions are the same way. https://github.com/mozilla-services/squid-rpm/blob/master/SO... ... however ... whatever that is, does. Did they take this upstream init script somehow?
Earlier quoted context omitted.
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.
or check the variable before using it, like any other programming language: [[ "$VAR" ]] && rm -rf "$VAR/*" I think most of these issues stem from the fact that most developers that write shell scripts don't actually understand what they're doing, treating the script as a necessary annoyance rather than a component of the software.
some real-world programming languages don't have undefined variables :)
Earlier quoted context omitted.
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…
The original example was `rm -rf "$STREAMROOT/"*`, though (the asterisk being out of the double quotes.) Now that glob will expand.