12 ms·
Bug 1202858 – Restarting squid results in deleting all files in hard-drive
- deleted 12y ago[deleted]
- anh79 12y agoMaybe I would add a new record to this https://github.com/icy/bash-coding-style#good-lessons https://github.com/icy/bash-coding-style#good-lessons
- zx2c4 12y ago"Thanks Swapna and Red Hat QE for catching this issue before the package was released. Great work!" Looks like this wasn't released into production.
- stefanha 12y agoThis comment should be at the top. False alarm, squid users, and now back to our regularly scheduled HTTP proxying. For more details on why this issue doesn't affect squid users: https://rwmj.wordpress.com/2015/03/24/restarting-squid-results-in-deleting-all-files-in-hard-drive/ https://rwmj.wordpress.com/2015/03/24/restarting-squid-resul...
- fermigier 12y agoScary. 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 ?
- rwmj 12y agoIt's already fixed, plus there are many private comments which you cannot see (but I think you see "missing" comment numbers). Also the product in question is not released yet. It's good this was found, but no customer would have been affected unless they were using an alpha.
- deleted 12y ago[deleted]
- cynix 12y agoRedHat is pleased to announce the general availability of our new RedHat Enterprise Data Recovery service. Please contact your account manager for details.
- TheDong 12y agoIt already has a "fixed in version" listed. Fixing it within a day doesn't sound like no one caring :) Does it really matter if no one commented "Oops, we screwed up"? It's kinda self-evident that there was a mistake and there's not really much to say; it's clear from the description how bad it is and marking it "Fixed in version" already says it all pretty much.
- EdwardDiego 12y ago> Does it really matter if no one commented "Oops, we screwed up"? To me it does. You just deleted someone's hard drive, an apology wouldn't be out of order.
- TheDong 12y agoWhen you're a QA engineer at RHEL working on an UNRELEASED PRODUCT then no, I don't think you need an apology. Maybe a thanks for finding the bug, but this is the whole point of QA and the whole point of QA-ing before it's released. The context matters a lot. This title is linkbait. It omits mentioning that this was not publicly released and the reporter is a QA for Red Hat. Given that context I doubt you'll still agree an apology is so necessary or that this was not handled well.
- kevan 12y agoI love how deadpan the bug report is: Actual results: All files are deleted on the machine. Expected results: Squid is restarted. Not many details yet but it sounds similar to the Steam bug [0] from last year. [0] https://github.com/valvesoftware/steam-for-linux/issues/3671 https://github.com/valvesoftware/steam-for-linux/issues/3671
- stevenspasbo 12y agoI started laughing at the lines Stopping squid: ................[ OK ] rm: cannot remove `/boot': Device or resource busy
- blcknight 12y agoExcept the Valve bug passed their QE process if any and got out into the wild. This is for an unreleased version of RHEL, and was caught....
- TazeTSchnitzel 12y agoQE? Is that a misspelling of QA, or is there another meaning beyond Quantitative Easing?
- blcknight 12y agoQuality engineering. It's Red Hat's term, as well as a few other software companies, but its QA.
- TazeTSchnitzel 12y agoOh I see. Thanks.
- philk10 12y agoThough QA is Quality Assurance when really it's QC )Quality Control) that should have caught the error. QA puts processes into place that means there is a QC that can catch this. Sorry, going off-topic but as a tester I dislike being told to 'QA this'
- elchief 12y agoWe 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.
- VieElm 12y agoPretty terrible that such a thing is even allowed by Windows. This is why as a user I like Apple's OS X sandbox.
- antientropic 12y agoSimilar things have happened on OS X: http://apple.slashdot.org/story/01/11/04/0412209/itunes-20-installer-deletes-hard-drives http://apple.slashdot.org/story/01/11/04/0412209/itunes-20-i...
- coldtea 12y agoParent said "This is why as a user I like Apple's OS X sandbox.". This is a bug from 15 years ago, much much before the sandbox feature was introduced. A sandboxed iTunes would have prevented that.
- makomk 12y agoA sandboxed iTunes would also prevent syncing your iPod and importing existing music collections, because those both require access to files outside the sandbox, which is probably why Apple hasn't done that.
- aroch 12y agoPrograms can read files outside their sandbox if they're asked to by user input[1]. Sandboxing does not prevent interaction with USB devices [1] See "Powerbox and File System Access Outside of Your Container" at https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html https://developer.apple.com/library/mac/documentation/Securi...
- akandiah 12y agoIt looks like the start-up/shutdown script is doing an rm -rf on a bash variable that's evaluating to null.
- rosser 12y agoIf that is, in fact, the case, it is indeed a repeat of the Steam bug that 'kavan mentions elsethread.
- smrtinsert 12y agoIt's hard to trust anyone that would ever depend on such a variable without having some sort of precondition.
- spacemanmatt 12y agoAren't you glad for QA? Humans are inconsistent.
- TheDong 12y ago"it's hard to trust anyone that writes a dumb bug". Listen to yourself. We've all written dumb bugs. We've all had that one line of code that was an obvious mistake. I still trust people who write a bug here and there because if I didn't I would have to forgo trusting everyone for everyone makes dumb mistakes sometimes.
- lmm 12y agoAt this point I refuse to trust anyone who writes shell scripts. Bugs happen, but a shell script is practically guaranteed to have zero automated tests and variable-related bugs are all too common.
- lttlrck 12y agoSurely your distrust should be aimed at shell scripts not at everyone who has written one.
- 12y ago
- ffn 12y agoThanks OP, this actually made me laugh uproariously. Anyway, I'd be willing to bet 100 push-ups that (unless it was malicious and not a bug), this thing is caused by some clean up code somewhere that originally intended to do "rm -rf /path/to/squid/socket" but the function that was suppose to generate the "/path/to/squid/socket" string instead generated a null which was then parseString'd onto a "" via some + function that was trying to do "/" + null. But I'm neither a redhat user nor an OS dev, so I might completely wrong.
- deleted 12y ago[deleted]
- profmonocle 12y agoThat's almost exactly how I blew up a test server once. (rsync --delete in place of rm) Taught me to be extremely careful when dealing with absolute directory paths.
- marcosdumay 12y agoOh man... Rsync deserves extreme caution even compared with other bash commands. It's so easy to erase everything and copy terabytes again.
- mplewis 12y agoI'm having trouble finding the related commit that fixed this, can anyone else find it?
- rwmj 12y agoThis bug is an internal QA bug. The reporter is a Red Hat tester. The buggy RPM was never released outside Red Hat, and so there's no requirement to release the source. When RHEL 6.7 comes out the source will go up on ftp.redhat.com.
- int19h 12y ago10 bucks says the lesson learned will be "remember kids, always set -u (and other good ideas, like set -e, set -o pipefail, and personally I like set -o posix but you'll need to give up process substitution for that)."
- thaumaturgy 12y agoHmm, 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 SQUID_PIDFILE_DIR isn't empty (or, better yet, is in /var and doesn't contain ".."), and either the submitter's copy of the script is mangled or something else somewhere is stomping on SQUID_PIDFILE_DIR in the shell environment. ...I should grep my init scripts for "rm".
- rachelbythebay 12y agosquid-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/SOURCES/squid.init https://github.com/mozilla-services/squid-rpm/blob/master/SO... ... however ... whatever that is, does. Did they take this upstream init script somehow?
- ato 12y agoThis looks like it: https://bugzilla.redhat.com/show_bug.cgi?id=1102343 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.
- thaumaturgy 12y agoOh, good call. Yeah, you found it.
- thaumaturgy 12y agoThat would be my guess too, although the package maintainer confirmed it on (presumably) a fresh install. I can't find a candidate rm command anywhere in the SRPM, so maybe an upstream file got merged into distrib somehow? I don't have access to an RHEL system to try it out, and can't find the distrib RPM yet to check.
- jedisct1 12y agoMy good old trick to mitigate that is: touch /-@ I also always do it in my home directory: touch ~/-@ That's the first thing I do on a new host. 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 ...
- ulrikrasmussen 12y agoWhile this is a really nice hack, stuff like this is also the reason I feel really uneasy when writing shell scripts. What works now may suddenly break in the future due to inadequate escaping of filenames.
- liviu- 12y agotouch /-- rm -rf * (admittedly, this would be a malicious attempt rather than a careless bug)
- miles 12y agoNeat idea! Just tested that in an OS X 10.8 virtual machine; while it works nicely against "rm -rf *", sadly it does not help stop an accidental sudo rm -rf / or ~/. Also, "touch ~-@" created a file in the home directory called "~-@"; in order to set the correct filename, I cd'd into ~ and then ran "touch ./-@".
- amadvance 12y agoLikely you mean: touch ~/-@
- atmosx 12y agoHm that's a cool trick. IIRC some distributions (Suse?) had a 'bash' clause where you couldn't do "rm -rf /" without 'y'. My 'zsh' has this one too, when I 'rm -rf /some/dir/' always asks if I'm "sure". Truth to be told, I'm not even expecting the text in "stdout" anymore, my finger goes to the 'y' automatically, which means that if I make something stupid it won't be able to protect me :-P The last couple of years I stopped doing 'stupid things' by stop working on the shell when I'm very tired. That was the cause of my rm-related-incidents in the past :-)
- deleted 12y ago[deleted]
- deleted 12y ago[deleted]