Python as network protocol
steve at REMOVE-THIS-cybersource.com.au
Tue Nov 10 16:56:56 CET 2009
On Tue, 10 Nov 2009 16:31:13 +0100, Daniel Fetchinson wrote about using
>> 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
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
More information about the Python-list