Ruby/Python/REXX as a MUCK scripting language

[Tony Belding]

I'm interested in using an off-the-shelf interpreted language as a
user-accessible scripting language for a MUCK. I'm just not sure if I
can find one that does everything I need. The MUCK must be able to
call the interpreter and execute scripts with it, but the interpreter
must also be able to call functions in the MUCK code. And then there's
the security issue that really worries me. . . I have to be able to
limit what the interpreter can execute. I can't have my users running
scripts that access the console, access the filesystem or sockets
directly, or call libraries or other binaries outside the MUCK.

Is this practical? I'm thinking of Ruby or Python for this, if they
can meet the requirements.

I might even consider REXX. . . I remember ARexx from my Amiga days,
and how great it was for string manipulation and application scripting.
However. . . My immediate target platform, Mac OS X, comes with Ruby
and Python but not REXX, so that's a disadvantage.

My final option would be to create my own language interpeter where I
have control over everything that happens. That is what MUCKs have
always done in the past. But the result was always quirky, limited
languages like MUF (Multi-User Forth) which really turn off a lot of
coders. Furthermore, I've never created a language before, and it
would be a lot of extra work for me.

--
Tony Belding, Hamilton Texas

[Cameron Laird]

In article <ek**********@u psn250.cri.u-psud.fr>,
Laurent Pointal <la************ *@limsi.frwrote :

>Fred Bayer a écrit :

>>
Tony Belding wrote:

>>I'm interested in using an off-the-shelf interpreted language as a
user-accessible scripting language for a MUCK. I'm just not sure if I

[Laurent Pointal]

Cameron Laird a écrit :

In article <ek**********@u psn250.cri.u-psud.fr>,
Laurent Pointal <la************ *@limsi.frwrote :

>Fred Bayer a écrit :

>>Tony Belding wrote:
I'm interested in using an off-the-shelf interpreted language as a
user-accessible scripting language for a MUCK. I'm just not sure if I

.
.
.

>>>there's the security issue that really worries me. . . I have to be
able to limit what the interpreter can execute. I can't have my users
running scripts that access the console, access the filesystem or
sockets directly, or call libraries or other binaries outside the MUCK.

Is this practical? I'm thinking of Ruby or Python for this, if they
can meet the requirements.

Don't forget Lua: www.lua.org
It fulfills your requirements and is easily embedable.

I Agree with F.Bayer, when reading OP post, I immediatly think about Lua.

Does Lua have an appropriate security model--a sandbox or such?
Fond though I am of Lua, such would be news to me.

I dont think of a security model like in Java, but in the possibility to
limit the accessible libraries for interpreted code.

http://www.lua.org/manual/5.1/manual.html#5

If OP just need some computation logic, he could limit external world
communication libraries (these libraries must be loaded by the C host
program before being usable by scripts).
Need to look more precisely to the minimum library set to load and to
available functions in this set. Maybe it is possible to remove some
undesired functions from Lua symbol tables just after loading libraries.
[note: I have still not used Lua, but I look at it for futur use in a
current development where an embedded Python would be too heavy and make
problems relative to the GIL - but I'm still a Python fan in other use
cases]

A+

Laurent.

[Cameron Laird]

In article <ek**********@u psn250.cri.u-psud.fr>,
Laurent Pointal <la************ *@limsi.frwrote :

> .
.
.

>>>>there's the security issue that really worries me. . . I have to be
able to limit what the interpreter can execute. I can't have my users