3 ms·
I 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 ha
by bayareaguy 19y ago
I 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.