Ruby Sandboxing VS. Integrating a Scripting Language

Ruby sandboxing vs. integrating a scripting language

You might consider using the Shikashi gem, which allows you to create sandboxes and define a whitelist of allowed method calls on individual objects.

Ruby: looking for ruby-embeddable interpreter or scripting language

FWIW, I ended up tweaking a version of stickup to use as a embeddable interpreter. The process was fast and easy and serves my needs well. (And besides, I used to work for a Common Lisp company, so it was an excuse to re-live the joys of s-expressions.)

Ruby vs Lua as scripting language for C++

I've used Lua extensively in the past.

Luabind is really easy to use, there is no need for an external generator like SWIG, the doc is great. Compile times remain decent.

Biggest problem I've seen : lua is mostly ... write-only. You don't really have classes, but only associative arrays with a bit of syntaxic sugar ( object['key'] can be written object.key ), so you easily end up adding a 'member' in an obscure function, completely forget about it, and have side effects later.

For this reason, and this reason only, I'd prefer Python. Boost::Python is the basis for Luabind so both have a similar API (Luabind used to be slightly easier to build but not anymore). In terms of functionality, they are quite equivalent.

Not directly related : None of these can be reliably used in a multithreaded environment (so this depends on the complexity of your server).

• N Python threads : the GIL ( Global Interpreter Lock ) is on your way. Each and every time you use a variable in a thread, it's locked, so it kinda ruins the point, except for long I/O operations and calls to C functions.
• lua has coroutines, but they aren't parallelisable.
• Ruby threads aren't really threads, but similar to Lua's coroutines

Note that you can still create one environement for each thread, but they won't be able to communicate (except with a C++ machinery). This is especially easy in Lua.

Executing arbitrary functions in Ruby without the security problems of eval

Run arbitrary code it is a unsafe practice and very difficult to ensure that you control all variables and different scenarios.

You can try to patch all Ruby classes/ modules that can run any malicious code, like IO, Kernel, etc, but in the end you will have many classes patched, very difficult to maintain and will not have sure if it will work safely.

The best solution that I can figure out is to create your own programming language where you can ensure all functions and operations that the user will have access.

Nowadays there are many solutions, paper and examples that makes this task not so difficult, for example Ragel http://www.complang.org/ragel/ that compiles to Ruby.

You can start with few operations (if, arithmetic, logic, etc) and improve it incrementally. In the end, you will have a robust solution that can easily evolve to fit on users needs.

End-user scripting

Lua has good sandboxing capabilities and is clean and simple.

It has the setfenv() function that can run code in a specific environment. The untrusted code can only access what is in the specific environment.

For C functions, such as string.rep, you can prevent memory over-consumption by replacing them with Lua functions or providing a custom memory allocator to lua_newstate.

Also, if you decide that you wish to use Lua for trusted code and have it interface with untrusted code, you can use coroutines and debug.sethook to control CPU usage.

The Lua Wiki has a simple example sandbox.

The source code of the lua live demo might be of interest, too.

Which scripting language to support in an existing codebase?

Based on my own experience:

• Python. IMHO this is a good choice. We have a pretty big code base with a lot of users and they like it a lot.
• Ruby. There are some really nice apps such as Google Sketchup that use this. I wrote a Sketchup plugin and thought it was pretty nice.
• Tcl. This is the old-school embeddable scripting language of choice, but it doesn't have a lot of momentum these days. It's high quality though, they use it on the Hubble Space Telescope!
• Lua. I've only done baby stuff with it but IIRC it only has a floating point numeric type, so make sure that's not a problem for the data you will be working with.

We're lucky to be living in the golden age of scripting, so it's hard to make a bad choice if you choose from any of the popular ones.

embedded scripting language deep rationale

All of the benefits of scripting now applied equally then. So you can immediately award points for:

• separation of concerns — the level designer and the engine programmer almost needn't even be on talking terms as the specific game becomes a separate project from the main body of the code; and
• faster prototyping and experimentation — Freescape's scripting language is compiled into byte code but the scripts tend to be very short versus the weight of the entire game, so trying out changes is faster.

In addition, the Freescape engine was a huge, expensive development for the time — they spent 14 months on it versus the month or two that most contemporary products received. Scripting all game logic achieved a significant secondary goal for them: portability.

The first Freescape game, Driller, uses exactly the same data and scripts across all of its releases. They had to build that out for the Spectrum, the CPC, the C64, the Amiga and the PC (a total of four CPU architectures, for a project that will have needed to be written in assembly language), but once that was done the game logic was write once, run anywhere — it became very easy to build subsequent games and release them simultaneously across the board.

Counting the 3D Construction Kit, they managed to publish five major games and two minor ones (Total Eclipse II and Castle Master II, both to juice up rereleases of the main title) over the following four years.

Portability isn't so much of a problem now as people use higher level languages and are generally isolated from the hardware, but prototyping and separation are just as important as ever.

Has Lua a future as a general-purpose scripting language?

I think it has a great future, a lot of projects are starting to adopt it for it's simplicity and usefulness.

Example: Awesome WM (Window Manager)

The project recently released version 3, incorporating a new configuration system completely written in Lua. Allowing you to literally write your configuration file as a program, loops, booleans, data structures.
Personally I love the syntax and the flexibility of such a system, I think it has great potential.

I wouldn't be surprised if it became more popular in the future.

Brian G

---

Related Topics