3 ms·

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 fa

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.

deleted 4y ago
[deleted]
thawaya3113 4y ago
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.
- clhodapp 4y ago
  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).
kadoban 4y ago
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.
- jonwest 4y ago
  Right—and that's not a "faulty script", that's a "faulty process for running scripts".
waste_monk 4y ago
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.
SahAssar 4y ago
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.

deleted 4y ago

[deleted]

thawaya3113 4y ago

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.

clhodapp 4y ago
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).

kadoban 4y ago

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.

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

waste_monk 4y ago

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.

SahAssar 4y ago

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.