[IronPython] Restricting IronPython

Markus Hajek markus.hajek at teamvienna.at
Fri Apr 6 15:33:12 CEST 2007


Hi,

 

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
be aborted.

 

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
attribute.

 

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,

 

Max Hajek

Vienna

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070406/36fcf60c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PythonEngine.patch
Type: application/octet-stream
Size: 453 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070406/36fcf60c/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReflectedPackage.patch
Type: application/octet-stream
Size: 614 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070406/36fcf60c/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attributes.patch
Type: application/octet-stream
Size: 154 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070406/36fcf60c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ReflectedType.patch
Type: application/octet-stream
Size: 1163 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20070406/36fcf60c/attachment-0003.obj>


More information about the Ironpython-users mailing list