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

Bug 1202858 – Restarting squid results in deleting all files in hard-drive

bugzilla.redhat.com

Post reply on HN
Print view View original

11–20 of 179 posts

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#11

Post by kevan »

viraptor wrote: post #7
kevan wrote: post #3

I 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

I would bet on the issue being in the init script itself rather than squid. (I'm assuming squid doesn't run as root by default in rhel) If that's true then it's another point for more sane process managers (upstart/supervisord/systemd/...)

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/"*

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#12

Post by ffn »

Thanks 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.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#13

Post by [deleted] »

kevan wrote: post #11
viraptor wrote: post #7

Earlier quoted context omitted.

I would bet on the issue being in the init script itself rather than squid. (I'm assuming squid doesn't run as root by default in rhel) If that's true then it's another point for more sane process managers (upstart/supervisord/systemd/...)

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]

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#14

Post by oogway »

fermigier wrote: post #2

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 ?

Well, the bug was reported against RHEL 6.7 which has not been released yet.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#17

Post by EdwardDiego »

TheDong wrote: post #6
fermigier wrote: post #2

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 ?

It 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.

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

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#18

Post by smrtinsert »

akandiah wrote: post #10

It looks like the start-up/shutdown script is doing an rm -rf on a bash variable that's evaluating to null.

It's hard to trust anyone that would ever depend on such a variable without having some sort of precondition.

Re: Bug 1202858 – Restarting squid results in deleting all files in hard-drive

#19

Post by TheDong »

EdwardDiego wrote: post #17
TheDong wrote: post #6

Earlier quoted context omitted.

It 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.

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

When 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.

Post reply on HN