3 ms·
Do not run this script, ever
- edw519 19y ago<post> * THIS IS MY POST * * DO NOT READ PAST THIS POINT OR YOU'LL DIE!!! * exit 1 (you'll die anyway) </post>
- bayareaguy 19y agoI don't generally keep scripts like that around where people can run them and if I must I change #!/bin/ksh to something else like #!/bin/cat. If I actually had to worry about working with someone like the guy in the article, I'd go further and create my own "shell" that would pretend to run the commands but would otherwise syslog/page me whenever someone actually ran it.
- dreish 19y agoThe newbie of this story jumped through two hoops to run the script "to find out what it does". He would surely jump through the hoop of changing it to a working shell as well. Obvious only in retrospect would be to remove the "DROP TABLE" commands. Those contain no useful information worth keeping around -- the CREATE TABLE commands do. Of course, the best and most general solution is exactly what he did: Keep backups and logs sufficient to rebuild everything up to the moment it was ruined. That will save his neck again someday, for a completely unrelated reason.
- marcus 19y agoWe actually encrypted the code of dangerous tools (we wrote in Perl back then) like this one with a password so the customers (telecoms) tech people, who were mostly clueless, wouldn't be able to play around with our tools. The program was just a tiny bit of code describing the tool, prompting for a password, tried to decrypt the code of the original program using the password and evaled the code.
- bayareaguy 19y agoInteresting idea. You would think the database user/password and a few grant/revoke statements would be sufficient to prevent issues like the one in the article.
- marcus 19y agoThe problem was the clients support staff had root access on all the machines.
- gruseom 19y agoIf the author really meant "do not ever run this script", he should have deleted it. Instead, he added a comment. When comments disagree with code, code wins. Rather than taking responsibility and learning this, he blames the stupidity of a newbie.
- almost 19y agoIt's useful to have those scripts around, you might want to do another installation somewhere or it might just be useful to see how the tables are meant to be if they get screwed up.
- gruseom 19y agoWell, sure. But then he didn't really mean what the comment said, which was "DO NOT EVER RUN THIS SCRIPT". There are any number of strategies he could have used to prevent what happened. The one he chose was to add an inaccurate comment to code and assume that every subsequent programmer would read it, understand its meaning, and do what it said. That's not just one fundamental mistake but several.
- eru 19y agoNo. It was not just comments. Did you read the line that says 'exit 1'?
- gruseom 19y agoFair enough. He also disabled run permissions on the script. But my point isn't really about "just comments", it's that good programmers take responsibility for failures that arise from their work. In this case, printing "DO NOT EVER RUN THIS SCRIPT" and exiting without doing anything led to misunderstanding and problems in the hands of a curious and inexperienced successor. Here the author had a choice to make. He could look at how his rather hokey strategy contributed to the failure or he could hype up the stupidity of the other guy.
- 19y ago
- Tichy 19y agoThat's why there are development environments and production environments.