Re: [YAY] my sandboxing extension!!

On Wed, Jul 19, 2006 at 06:40:34PM +0900, why the lucky stiff wrote:
> I have (what feels like) very exciting news.  I finally sat down to code up my
> sandboxing extension, based on what I've learned from Try Ruby.  This extension
> is written in C and is designed to open a blank symbol table, fill it with the
> basic boilerplate and eval a string within that environment.

Does that mean we'll soon see people opening their Try Ruby franchises? ;-)

> The extension contains a whitelist of methods and classes to move into the blank
> environment.  The code grabs the NODE for each method body and replants the
> CFUNC in the sandbox.  Allocators and singletons and all that get copied.
> 
> So how does it actually eval the code?  Well, it swaps out rb_class_tbl and all
> the rb_(m|c|e)\w+ variables just before eval.  Then, it rb_obj_instance_evals on
> an anonymous object (sandbox's `main`) inheriting from the new sandbox->cObject.
> I then rb_ensure and swap the normal vars back in.

So it doesn't support concurrent non-sandboxed Threads, right?

require './sand_table.so'
require 'timeout'

sbox = Sandbox.new
Timeout.timeout(1) do
  sbox.eval <<-EOF
    # 3v1l
    while true
    end
  EOF
end

hangs. To be fair, there are many ways to circumvent timeout, so the sandbox
would normally execute in a separate process (the way you do with Try Ruby
IIRC). 

This makes me think that the point of sandbox is not as much allowing access
to stuff you cannot use with higher $SAFE levels as offering a clean
environment. Am I right? In both cases, being able to specify which stuff is
to be imported could be useful.

Thank you,

-- 
Mauricio Fernandez  -   http://eigenclass.org   -  singular Ruby