I'm looking for something that allows
the user to perform a few simple operations in a sandbox context,
The important question for me is, why does this need to be a sandbox?
Something that would
allow me to compile the main program with ruby2exe and then load -- and
reload without interrupting the execution of the main program -- small
bits of script from an external source (e.g. a file) with.
If ruby2exe allows for 'eval', you could easily do it that way -- unless,
again, you want to "save users from themselves" somehow, by ensuring that when
their "script" crashes, it doesn't bring down your script.
But unless they're deliberately doing that, I don't really see what's wrong
with simply creating a well-defined framework and re-evaling their script. As
an example, look at Rails in development mode.
If you were doing this for Unix, you'd also have the nice strategy of forking,
then evaling (or simply 'load' or 'require'-ing), and communicating with the
parent process via pipes. With a COW-friendly GC (which I think Ruby 1.9 has),
this would be lightning-fast and not really more memory than a thread.
But the advantage of the fork-eval strategy isn't that it's more of a sandbox,
it's that they start with a clean slate each time, with all the libraries
loaded.
To bring things into context I have a game in which I would like certain
objects to be scriptable to some degree. Nothing extremely involved;
just a few methods, properties, and control structures. So essentially a
scripting "language" that can be provided a simple subset of the main
program's functionality
Yes, you're still talking about something that would be satisfied by making it
a "framework", by doing things like eval, load, or require, and running that
Ruby code with full privileges.
in a sandbox context that doesn't allow file and
network I/O, shell access, and all those other nifty things Ruby
normally does.
So the question is, what's wrong with that? Let's compare:
Something comparable to Unrealscript
As I understand it, this is essentially meant to script a game, so there's no
reason you'd restrict it in any way.
or Actionscript
Which does allow network I/O, it's just restricted to certain IPs/ports.
(which as I
understand is essentially Javascript)
Not really. I think later versions may have tried to make it a superset of
Javascript, but definitely early on, it was a sad attempt to "improve" on
Javascript.
Robert Klemme mentioned some techniques if you really need to sandbox it --
$SAFE looks particularly interesting.
I've mentioned a few others -- probably the most Unix-y way you could do this
is to provide a pipe-based API, where you send text over a pipe to any program
they want, which replies over the same pipe, and is otherwise unprivileged and
chroot'ed. I have no idea how easy this is to do on Windows, though I think IE
now does something similar on Vista.
But the question you haven't answered yet is why you want it sandboxed at all.
Is the idea that people could be downloading these scripts from the Internet?
···
On Monday 07 September 2009 11:57:18 am Tristan Shelton wrote: