On Tue, Nov 10, 2009 at 10:56 AM, Steven D'Aprano <st...@remove-this-cybersource.com.au> wrote: > On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using > exec: > >>> This is a *really* bad idea. >> >> How do you know for sure? Maybe the OP wants to use this thing with 3 >> known researchers working on a cluster that is not even visible to the >> outside world. In such a setup the model the OP suggested is a perfectly >> reasonable one. I say this because I often work in such an environment >> and security is never an issue for us. And I find it always amusing that >> whenever I outline our code to a non-scientist programmer they always >> run away in shock and never talk to us again > > You might be a great scientist, but perhaps you should pay attention to > the experts on programming who tell you that this is opening a potential > security hole in your system. > > No, it's not a "perfectly reasonable" tactic. It's a risky tactic that > only works because the environment you use it in is so limited and the > users so trusted. Can you guarantee that will never change? If not, then > you should rethink your tactic of using exec. > > Besides, as a general rule, exec is around an order of magnitude slower > than running code directly. If performance matters at all, you are better > off to try to find an alternative to exec. > > >> Nevertheless our code works perfectly for our purposes. > > Until the day that some manager decides that it would be great to make > your code into a service available over the Internet, or until one of the > other scientists decides that he really needs to access it from home, or > somebody pastes the wrong text into the application and it blows up in > your face... it's not just malice you need to be careful of, but also > accidents. > > The history of computing is full of systems that were designed with no > security because it wasn't needed, until it was needed, but it was too > late by then. > > There's no need, or at least very little need, to put locks on the > internal doors of your house, because we're not in the habit of taking > internal doors and turning them into outside doors. But code designed to > run inside your secure, safe network has a tendency to be re-purposed to > run in insecure, unsafe networks, usually by people who have forgotten, > or never knew, that they were opening up their system to code injection > attacks. > > > > -- > Steven
Steven, remember a few weeks ago when you tried to explain to me that the person who was storing windows administrative passwords using a 40 byte xor cipher with the hardcoded password might not be doing something stupid because I didn't know what their threat model was? Yeah- what you just said is what I was trying to explain then. Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
