Jeff Shannon wrote:
Because you cannot make Python secure against a malicious (or ignorant) user -- there's too much flexibility to be able to guard against every possible way in which user-code could harm the system. Parsing your own (limited) scripting language allows much better control over what user-code is capable of doing, and therefore allows (at least some measure of) security against malicious code.
I don't see how that would equate to something that the original programmer should be concerned about. You could include a bit in your licensing scheme that voids all support on code that has been modified in any way. You shouldn't be obligated and no one expects you to support something the end-user has mucked with.
You could trivially enforce this by keeping checksums of all the system files.
You're thinking of two different situations. My guess is that Jeff Shannon is not referring to situations where the end user makes modifications to existing code, but rather, where the end user write *completely new* scripts in your new scripting language. As such, you can't enforce checksums - the code hasn't been written yet.
The use cases probably are also different. You're thinking of delivering a completed application to an end-user's machine, but given the OP's user name ("Quest Master"), my guess is that he's looking for a server-side deployment like in an on-line game, where users script the game environment. Not only do you have a problem with a malicious user potentially crashing the game machine, but you also have issues where the user may be able to grab his "character object" and give himself infinite money or life, or whatever. Since it's a shared server, you can't just say "I'm not supporting it" when someone mucks with the server.
> In any case, there's nothing you can really do to "secure" your code. > This is true of any language, C, C++, and especially scripting languages > like Python. Anyone who has the determination get at and modify the code > probably will.
Well, if you don't provide mechanisms for disk access, there is no way to overwrite files, short of a bug in the interpreter (or some extension interface to a general purpose programing language). Python is just to flexible to work like that. Even if you don't provide an open function to user code, and eliminate questionable modules, you can still get a file object, even if all you are provided with is an integer object. That's why restricted execution was eliminated from the standard library.
--
http://mail.python.org/mailman/listinfo/python-list
