Before I get into how to lock down the sandbox, let’s talk about what kinds of nifty things you can do with it when you’re just running your own code.

 dir_proc = proc { Dir['/*'] }

 require 'sandbox'
 sbox = Sandbox.new
 sbox.eval("Kernel").module_eval do
   define_method(:root_directory) do
     dir_proc.call
   end
 end

This is the “plain” Sandbox mode. Sandbox.new. It’s not as focused on security. You can pass objects in and out. So eval("Kernel") gives us the Kernel in the sandbox. Here’s proof:

 >> Kernel.method(:p)
 => #<Method: Kernel.p>
 >> sbox.eval("Kernel").method(:p)
 undefined method `method' for Kernel:Module (NoMethodError)

So “plain” mode lets us add directly to the objects. In the first example, a method gets added to the sandbox Kernel. A proc is used to get a scope that’s outside the Sandbox. (Sandboxes clear out Ruby’s scope list.)

 >> sbox.eval("root_directory")
 => ["/usr", "/var", ...]

And, check it out, no method on the real Kernel. But you can copy it back if you like.

 >> Kernel.respond_to? :root_directory
 => false
 >> Kernel.send :define_method, :root_directory,
 ..   &sbox.eval("Kernel.method(:root_directory)")
 >> Kernel.send :root_directory
 => ["/usr", "/var", ...]

I envision Railsers will use this to keep the web server in contact with apps mounted in different sandboxes. Unless this rains havoc on Mongrel’s threads. I guess we’ll see!