Another scripting language implemented into Python itself?

Rocco Moretti roccomoretti at hotpop.com
Tue Jan 25 14:44:15 EST 2005


Orlando Vazquez wrote:
> 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.



More information about the Python-list mailing list