[MUD-Dev] Re: Scripting Design Notes

[Jo Dillon]

Chris Gray (cg at ami-cg.GraySage.Edmonton.AB.CA) spake thusly:
> [Mike L Kesl:]
> 
> 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.

  Java does have a security manager system, which is used by applets
 - you could certainly prevent use of the IO stuff that way.
 
> 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

  It relies on a cross-platform class library that wraps native widgets
and functionality.

> 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

  I think Java byte order is the same on all systems; .class files /certainly/
have the same byte order and I don't think they get swapped round in memory.

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

  My own experience is that it can be up to about 20 times slower than C
without a JIT. /With/ a good JIT (like the one in IE 4) it can get to maybe
80% of native code speed.
 
>  >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!

  Java security can fix this, I think :)
 
> -- 
> Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
> 
> -- 
> MUD-Dev: Advancing an unrealised future.

--
	Jo

Harmony - the project to create an LGPL Qt clone
http://harmony.ruhr.de