[MUD-Dev] Re: Scripting Design Notes

[Chris Gray]

[Mike L Kesl:]

 >I am considering using jPython <http://www.python.org>. The other
 >consideration is to allow contributors to use java in a secure way
 >using a hard coded api of appropriate scripting functions. I think
 >something that is purely interpreted would be nice, but I am not sure
 >if that is theoretically possible in a purely platform independent
 >project, unless of course if the interpreter is written in java, which
 >could mean a class library in the case of jPython, I am not sure.
 >Otherwise we would have to write our own interpreter for the java
 >method. This method would really only try to compile the script, making
 >the java runtime environment do most of the work. More investigation of
 >Java Python is necessary, and perhaps other languages.

Well, if you use Java, your scripting language *is* portable, but likely
more powerful than you want. Where will the scripted code run? Most
likely in the server, in which case things like all of 'awt' should
be disallowed. Likely also all of the IO stuff. You could take the
Java source they write and wrap it inside some special stuff that
imports a bunch of utility routines that you *do* want them to be able
to use, then compile the result. However, you are still vulnerable.

Writing a portable interpreter in C or C++ can certainly be done. The
Java interpreter itself is an example. (I doubt if Netscape has completely
different source code for different platforms - its likely a lot of
conditional compilation, etc.) You have to watch for byte-order
issues (your byte-code will likely have a fixed byte-order, and you will
have to account for that on systems where the native byte-order is
different). There are also issues of alignment - some CPUs/systems are
more strict about it than others (RISC chips are usually quite strict).
Writing an interpreter of any kind in Java will yield something that
may well be unusable slow. Java itself isn't very fast (I've heard
of it being upto 300 times slower than C/C++ code, but that is
probably an extreme case).

 >The most obvious security threat is that a scripter could call
 >functions in the code he or she should not be. This problem is
 >eliminated by the very definition of a scripting language. Avoiding
 >this problem is usually the main part of the scripting language tied
 >closely together in a brawl with flexible functionality.

If you define your own scripting language, or can manage to fully block
access to "unsafe" things, its probably a good thing to do. Crashing
your MUD is one thing, but you certainly don't want people to be able
to do things like access/modify/delete files on the host system!

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA