Ruby/Python/REXX as a MUCK scripting language

Discussion in 'Python' started by Tony Belding, Nov 25, 2006.

  1. Tony Belding

    Tony Belding Guest

    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
     
    Tony Belding, Nov 25, 2006
    #1
    1. Advertising

  2. On Fri, 24 Nov 2006 18:11:21 -0600, Tony Belding <>
    declaimed the following in comp.lang.python:

    > 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

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
     
    Dennis Lee Bieber, Nov 25, 2006
    #2
    1. Advertising

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


    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.
     
    Timothy Goddard, Nov 25, 2006
    #3
  4. Tony Belding wrote:

    > 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
     
    Stephan Kuhagen, Nov 25, 2006
    #4
  5. In article <7fN9h.3177$>,
    Dennis Lee Bieber <> wrote:
    >On Fri, 24 Nov 2006 18:11:21 -0600, Tony Belding <>
    >declaimed the following in comp.lang.python:
    >
    >> 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.

    .
    .
    .
    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.
     
    Cameron Laird, Nov 25, 2006
    #5
  6. Tony Belding

    Fred Bayer Guest

    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
    > 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.
     
    Fred Bayer, Nov 25, 2006
    #6
  7. Tony Belding

    rony Guest

    Hi Tony,

    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
    > 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 <news:comp.lang.rexx>) 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)? :cool:)

    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!
     
    rony, Nov 25, 2006
    #7
  8. Tony Belding

    i Guest

    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.
    >
    > --
    > Tony Belding, Hamilton Texas


    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
     
    i, Nov 26, 2006
    #8
  9. In article <2006112418112116807-zobeid@techiecom>,
    Tony Belding <> wrote:

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

    --
    Jeremy C B Nicoll, Edinburgh, Scotland - my opinions are my own.
     
    Jeremy C B Nicoll, Nov 26, 2006
    #9
  10. Tony Belding

    Guest

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

    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
    > 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
     
    , Nov 27, 2006
    #10
  11. 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
    >> 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.
    >


    I Agree with F.Bayer, when reading OP post, I immediatly think about Lua.
     
    Laurent Pointal, Nov 27, 2006
    #11
  12. In article <ekel45$351$-psud.fr>,
    Laurent Pointal <> wrote:
    >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.
     
    Cameron Laird, Nov 30, 2006
    #12
  13. Cameron Laird a écrit :
    > In article <ekel45$351$-psud.fr>,
    > Laurent Pointal <> wrote:
    >> 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.
     
    Laurent Pointal, Dec 1, 2006
    #13
  14. In article <ekosg4$ljp$-psud.fr>,
    Laurent Pointal <> wrote:
    >> .
    >> .
    >> .
    >>>>> 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

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

    .
    .
    .
    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.
     
    Cameron Laird, Dec 1, 2006
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ron Stephens
    Replies:
    23
    Views:
    2,929
    Ron Stephens
    Apr 12, 2004
  2. Steven Bethard
    Replies:
    29
    Views:
    743
    Nick Craig-Wood
    Jan 30, 2005
  3. DaveInSidney
    Replies:
    0
    Views:
    437
    DaveInSidney
    May 9, 2005
  4. Replies:
    1
    Views:
    126
    Michele Dondi
    Oct 2, 2007
  5. PerlFAQ Server
    Replies:
    0
    Views:
    131
    PerlFAQ Server
    Apr 8, 2011
Loading...

Share This Page