Hacker News Reader

Comment by taspeotis | Hacker News Reader

“A script was executed incorrectly” does not blame anyone. Saying a script was faulty obfuscates what happened.

It is faulty though? There should be more that's required to accidentally delete data than a manually specified switch.

I mean, if it’s got flags to represent what you’re asking it to do and you set the wrong flag that’s not a script issue. I can run rm -rf / and that’s not a fault of rm, that’s a behind the keyboard issue.

No. That is a fault of rm that it makes it so easy to do something that in 9.99999% of the cases isn’t what the user wants to do.

In fact, recognizing that is precisely why you can’t even do that easily anymore. Setting aside that you probably need to sudo the function, rm prevents you from running the command unless you pass an additional long flag that basically say you really really want to do this.

Programs which expect perfect user input, and allow minor user mistakes to lead to major negative outcomes are faulty programs.

Adding a hardcoded extra check for / to rm feels like theater because it barely makes it more safe. It's nearly as damaging to most Linux systems to remove /bin or /usr or any number of other directories. If you wanted to actually solve this problem, it seems like you would need to add some kind of "dangerous-to-remove-this" metadata in the filesystem.

Nonetheless, even with rm you can override the check you mentioned with a flag. In principle, that seems to support the post you are referring to, not refute it (not in detail but in spirit).

It's a process issue that a script like that is ~commonly used on production data. Processes should be in place where that's essentially impossible to do wrong. "oops I passed the wrong flag" isn't user error, that's system error that it was set up like that.

Right—and that's not a "faulty script", that's a "faulty process for running scripts".

On most modern systems you can't, not without going out of your way to specify --no-preserve-root.

It sounds like they have a "type system" problem, e.g. you shouldn't be able to give a script an ID for a "cloud site" when it was expecting an ID for an application. That is, this sort of outage should not have occurred because it should not have been representable to begin with.

rm literally has a specific handling of / that requires the `--no-preserve-root` flag to allow you to run that. Software should generally warn before being super destructive, and it's usually best if the process for doing something super destructive and day-to-day use are very different.

Reply on news.ycombinator.com