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.

 

[Dennis Lee Bieber]

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

That is going to be the killer... Python no-longer ships with a
"secure sandbox" module, because there were always ways to work around
it.

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.

As I recall, the FuzzBall server required users to be vetted for MUF
programming privileges, because it too could not be made secure --
practically all objects within the MUCK involved MUF. Users could access
pre-made routines via normal command entries, but could not code at the
MUF level. FurryMUCK and FurToonia both implemented MPI as a general
user level scripting language. MPI is sort of a LISPy language; as it
was implemented "within" the MUF world (even though it /is/ C source),
it was possible to make it secure -- but it is not a stand-alone
language, even within it one is invoking the prebuilt MUF subroutines.

http://www.cs.wisc.edu/~bolo/shipyard/mpintro1.html
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Timothy Goddard]

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.

Sandboxing is possible in recent versions of Ruby using _why's sandbox
package (http://code.whytheluckystiff.net/sandbox/). For a MUCK a
custom language might be better though - creating sandboxes for any
conventional language is likely to be too expensive to repeat for a
thousand objects at regular intervals. A custom language would make it
much easier to manage security while retaining decent performance.

 

[Stephan Kuhagen]

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

Python had a sandbox module, but is was discarded because of security
problems.

If you want it working on MacOS, you may also have a look at Tcl, which has
a long tradition on MacOS and it comes with a very good implemented and
fully customizable sandbox. For a starting point, if Tcl sandbox meets your
requirements, have a look here:

Safe Tcl Overview: http://www.tcl.tk/software/plugin/safetcl.html
Docs about the specific Tcl commands, to create safe interpreters:
http://www.tcl.tk/man/tcl8.4/TclCmd/interp.htm (See in the lower third of
the page at "Safe Interpreters")
http://www.tcl.tk/man/tcl8.4/TclCmd/safe.htm

Regards
Stephan

 

[Cameron Laird]

That is going to be the killer... Python no-longer ships with a
"secure sandbox" module, because there were always ways to work around
it.

.
.
.
Tcl's the one language in this area that has gone the farthest
with its "safe interpreter" <URL: http://wiki.tcl.tk/4204 >,
and Tcl is well-supported under Mac OS.

 

[Fred Bayer]

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.

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

 

[rony]

Hi Tony,

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.

Well, a few remarks here ad the REXX options that would be available to you:

- REXX (there was its 25th anniversary celebrated in 2004) has an object-oriented successor that
still can execute plain REXX code, but is realized as an object-oriented language: Object REXX. It
got originally developed by IBM, after their big customers indicated that they would be interested
in it. In 1997 Object REXX became part of OS/2 Warp 4. IBM sold Object REXX for AIX and Windows.

- In 2004 after negotiations took place with the non-profit Rexx Language Association (RexxLA,
http://www.RexxLA.org), IBM handed the source code of Object REXX over to the RexxLA which created a
free and open source version and distributed it in April 2005 for the first time as Open Object Rexx
(ooRexx) 3.0, cf. <http://www.ooRexx.org>).

- The ooRexx source-code is hosted on Sourceforge and uses the Common Public License (CPL) 1.0 (cf.
<http://www.opensource.org/licenses/cpl1.0.php>). This means that you can freely use the code, edit
it your way and make it even part of your own (even commercial) product.

- This week a new drop of ooRexx, version 3.1.1, has been released, with binaries built for AIX
(first time that an official ooRexx binary got build for it!), Linux, MacOSX (first time that an
official ooRexx binyry got build for it PPC, Intel), Solaris (Intel, Sparc), and Windows.
[Additional binaries for additional environments can be built using the autoconf tools.]
So ooRexx has been made available for your main target platform for your MUCK application.

- Ad your needs w.r.t. calling functions of your MUCK applicaiton: yes, that is possible (and not
difficult at all).

- Ad your needs w.r.t. security needs of your MUCK application: yes, that is possible (and not
difficult at all):
Because of the history of ooRexx (it was a commercial product to be deployed at large sites,
security was a paramount issue), there is a Security Manager built into ooRexx.
The ooRexx security architecture is quite interesting, easy to use, very flexible as it allows you
to create as many differenct security policy rules as you may wish. The ooRexx security manager will
monitor all potential insecure actions from REXX and ooRexx programs (like accessing the
environment, accessing streams, accessing functions etc.) and inform the policy program about such
intended, possibly secure-threatening operations. The policy program then is able to decide to let
the action through, to execute a secure operation instead without the supervised REXX or ooRexx
program noticing this (!), or stop the execution of the supervised program alltogether.
If you are interested in this and need ideas, help for your MUCK needs, then please post, such that
people over here (ie. the <can help you out.

- Ad ooRexx in general: it is an easy to learn and easy to use (follows still the original REXX
philosophy to be a "human centric" language!!), fully object-oriented language (influenced by
Smalltalk). There is a small, tutorial-like paper (written for this year's European Conference of
Object-Oriented Programming, ECOOP, workshop named "Revival of Dynamic Languages (RDL)
<http://prog.vub.ac.be/~wdmeuter/RDL06/>", which really gives a brief overview of the history and
the (interesting) features of the ooRexx langauge, entitled "Resurrecting REXX, Introducing Object
Rexx", to enable reflection and discussion of the language and its interesting concepts, cf.:
<http://prog.vub.ac.be/~wdmeuter/RDL06/Flatscher.pdf>. At the end of the paper there are a few, but
actually quite impressive nutshell examples, demonstrating the ease and power of ooRexx in different
environments.

- Ad prospects of ooRexx: ooRexx is actively being developed and enhanced. The RexxLA has been
organizing a yearly "International Rexx Symposium", the 2007 symposium to probably take place in
Tampa, Florida, USA, from April 29th, 2007, through May 3rd, 2007. Maybe you or your partners may
want to stop by there (the conferences are rather personal, you get to meet everyone in person who
has been actively developing ooRexx and ooRexx applications)? )

Again, if you have any questions, please post them.

Regards,

---rony

P.S.: I have been using ooRexx in classes introducing MIS students to oo-concepts and programming,
such that "enduser-programmer" kind of people can successfully deploy their acquired skills to
automate/remote-control/script Windows, Windows applications, but also Java and Java applications
and applications like OpenOffice/StarOffice possessing Java interfaces. As a matter of fact, such
students become able to create scripts to drive e.g. OpenOffice which run unchanged e.g. on MacOS,
Linux and Windows, which is actually very cost-effective and impressive, if one thinks about it!

 

[i]

Tony Belding skrev:

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.

Regina REXX har a "restricted mode", but it doesn't allow external
calls so this is probably not a solution for You. Nevertheless, here
is an excerpt from the manual about that mode:

"2.6.3Regina Restricted Mode
Many language interpreters provide a mechanism where code executed
within that interpreter is
limited to affecting the environment of the interpreter and cannot
change the external environment
in which the interpreter runs.
Restricted mode is used in situations where you need to guarantee that
the author of a Rexx
program is unable to affect the user's environment.
Situations where a restricted mode is applicable include, using Regina
as a database procedural
language, or as a language plug-in for a Web browser.
Features of Regina that are disabled in restricted mode are:
· LINEOUT, CHAROUT, POPEN, RXFUNCADD BIFs
· "OPEN WRITE", "OPEN BOTH" subcommands of STREAM BIF
· The "built-in" environments eg. SYSTEM, CMD or PATH of ADDRESS
command
· Setting the value of a variable in the external environment with
VALUE BIF.
· Calling external functions
To run Regina in restricted mode, you can start the Regina interpreter
from the command line with
the '-r' switch, or when using the Rexx SAA API, or-ing RXRESTRICTED to
the CallType
parameter of RexxStart() function."

Thomas Berg

 

[Jeremy C B Nicoll]

My final option would be to create my own language interpeter...

If you're capable of doing that, I'd have thought you'd be capable of
taking the source code for Regina and modifying it so that either no
commands are passed to an external environment, or that only some are.
Surely that'd be less work than creating something from scratch.

 

[johnzenger]

Have you considered JavaScript Spidermonkey or JavaScript Rhino?
Sandboxing is automatic, and lots of people know the language already
(although fewer people are familiar with its dynamic object-oriented
capabilities).

 

[Laurent Pointal]

Fred Bayer a écrit :

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.

 

[Cameron Laird]

Fred Bayer a écrit : .
.
.

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.

 

[Laurent Pointal]

Cameron Laird a écrit :

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]

.
.
.

.
.
.

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]

.
.
.
I agree that Lua has a nice collection of primitives, and
there certainly is scope for security-related programming.
There isn't a body of work or precedent for polished results
in this area, though, ...

Good luck with the future use you anticipate.