[IronPython] Restricting IronPython
markus.hajek at teamvienna.at
Thu Apr 12 00:13:03 PDT 2007
thanks for the answer.
Isn't there a way to add a delegate to each executed (python) statement -
and do so in one place in the code base? I was thinking about a delegate
returning a Boolean. Only if it returns true, the statement is actually
executed. Otherwise something like "exit python" is executed.
Is there a place where I could add this instrumentation? And how would I go
about the "exit python" bit?
Team Vienna - Kazemi, Hajek & Pisarik OG
Von: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland
Gesendet: Freitag, 06. April 2007 23:43
An: Discussion of IronPython
Betreff: Re: [IronPython] Restricting IronPython
There's two ways I can think of how to enforce the time limit:
1. An external monitor which aborts the thread when a quantum has
expired. This has the problem of potentially aborting at any native CPU
instruction which most code is in no way prepared to handle. Therefore
2. Update CodeGen to emit checks to see if the current quantum has
expired. Most likely you'd want to do this on every back-branch within the
IL. I'm not sure how exactly you'd detect that w/o putting an abstraction
around the Label structure so you know where each label lives within the IL.
For compiler generated loops which you know to be bounded you could
eliminate the check also and only do it for user defined loops.
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Markus Hajek
Sent: Friday, April 06, 2007 6:33 AM
To: users at lists.ironpython.com
Subject: [IronPython] Restricting IronPython
I'm evaluating IronPython for use as a scripting language in a game server.
Designers would use it for game-logic.
Because designers typically are not engineers, one cannot expect them to
follow common good practices. So I need to restrict what their script code
can do in a few ways:
a. They should not be able to use any libraries other than what we
expose to them explicitly. That includes Python libraries (other than local)
and .NET-Framework libraries.
b. For framework classes it's necessary to expose only certain members
of these classes that are meant to be used from Python.
c. It should be possible to time-limit execution time of a script.
Designers might build scripts that under certain circumstances enter an
infinite loop or something similar. In such a case, script execution should
Now with a) it's easy enough to take away access to Python libraries.
Neither is there a problem with .NET framework stuff because you need to add
a reference explicitly - with two exceptions, mscorlib.dll and system.dll
are referenced automatically. I wrote a patch to get around this
(PythonEngine and ReflectedPackage). With this patch you have two boolean
properties in EngineOptions, AutoReferenceMscorlib and AutoReferenceSystem
which by default are set to true to keep behavior as it is, but can be set
to false, too, with the expected effect.
For b) it turns out there is no easy way of having a framework classes
expose only certain methods/properties by for example passing only an
interface to Python. That just doesn't work because Python will allow access
to any public member of the concrete instance. One way around that would be
to write adapter for each framework class (like: for class Player create
class PythonPlayer which holds an instance of Player as private member and
exposes only those members publicly that should be visible from Python), but
that would be tedious. So I created another patch (Attributes and
ReflectedType) which adds a new attribute [DoNotExpose] to IronPython.
Framework code writers can decorate properties, methods, fields, nested
types etc. with this attribute. Members decorated such won't be visible to
Python code. Again, by default behavior is not changed as no code has this
With c) I am stuck. I'm not at all sure where I could add such functionality
with minimum impact to the existing codebase.
Any ideas on that?
Besides, any feedback to the patches would be most welcome, too.
Happy Easter holidays,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users