Re: Opinion: Scripting in a Ruby program

On Monday 07 September 2009 11:57:18 am Tristan Shelton wrote:
> 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?