I was, inspired, by some of the previous posts talking about this type of stuff so I went out and spent some time researching various options. The thing itself isn't so difficult, writing the server, writing the client, communication, etc. The tricky part, and that part thats caused me to give up, is using perl as a scripting language. The problem with perl, of course, is that it's so powerful, that if you tried to use it as a scripting language people could easily mess up stuff, where stuff is the file system, your running processes, the game itelf, etc.

This is what I came up with to "Secure" perl as a scripting language.

Each object would basically have it's own perl code that described it. How exactly this would work I haven't decided yet, but it would be based around some sort of event module, so the code making up the module would be compiled, then some event would be passed to it, it would execute based on the event and return it's response, then the server would do stuff based on the response.

Step one, the server code decides it needs to execute an object, as it were, so it loads the perl code for that object and forks a new copy of the perl interpreter(open3(in,out,er,"perl");).

This child is then

1. Chrooted/chdired to an empty directory someplace
2. Rlimited, with fairly stricts limits on cpu time, memory and processes
3. The owner changed to a user with no privledges anywhere, read or write or exec.

Then the child gets passed the perl code that makes up the object, it executes it and passes back it's response (probably via a frozen datastructure of some sort which is thawed by the server) and the server does stuff based on the response.

As far as I can tell, this series of events should be ultimately secure -- in the sense that the object code cannot mess with the server or the system in any destructive manner.

The problem, is speed. Forking is slow, as people who use mod_cgi in apache well know. Forking and then execing perl, on my benchmark, could be done around 1500 times a second. Now in my benchmark, the exec'd perl didn't actually do anything, so doing lots of stuff will slow this figure down considerably. And even though this sounds like a really big number, it's not. 10 users in a room with 10 objects. Someone does something, 10 forks. The object does somethng, another 10 forks. Repeat for each user and object.

So in short, this doesn't sound practical, but I can't see another way of *safely* using perl as as scripting language. The "mod_perl" like solution, which is a long running process that executes this code, isn't practical for a number of reasons. The main one is that the process has to be seperate to be able to be chrooted/rlimited, and the strict rlimits would kill this process, and secondly because the perl code could interfer with other perl code, like on shared mod_perl servers.



(Note, I have looked at Safe, and while it looks nice, it can't prevent everything such as cpu or memory "attacks", and I don't particuraly trust it)

Update:
I did another fork benchmark, this time doing "exec perl -e'use CGI;'" after my fork in the "timethese" subroutine, and while it still claims "1428/s", it took 250 wallclock seconds to execute (0.00 usr, 0.70 sys + 217.93 cusr 27.38 csys = 246.01 CPU )so I suspect something isn't being properly accounted for. Probably because the fork's childrens cpu time isn't being counted or something. So forking a perl interpreter for every object is really a non good idea.