[Sputnik-list]luaenv.Sandbox (was : proposed versium modifications)

[pierre pracht]

Le 3 mars 08 à 09:06, Jim Whitehead II a écrit :

>>  values = luaenv.Sandbox:new{x = 1, y = 2}:do_lua("z = x + y")
>>    print(values.z)
>>
>> Or am I reinventing the wheel here?  I've looked at Rings and it  
>> seems
>> to allow something similar, but it seems to default to giving the
>> slave state access to _G and it also a lot more complicated (than 50
>> lines of lua, that is).  My idea was to route all user code through
>> something that is really simple, so that I could say that if you
>> worried about security, you should audit luaenv.  Also, not sure  
>> where
>> it should go.  There is one function in versium.storage.simple that
>> needs it right now, so perhaps it make sense to make it a part of
>> versium.  Anyway, assuming luaenv stays, I want to change it to the
>> object oriented API (see above) from the current functional.
>
> Ah, didn't realize that something in versium itself used it.  In that
> case, I would make it a simple rock.  Rings actually creates full lua
> states and allows message passing between them.  This is a nice,
> simple, no-frills way to execute code in a sandbox.  It seems to make
> sense to break the tie with versium.

Debugging is an other raison to put it in his own rocks.
If done you can easily change code to get some extra information to  
track down a bug.

In the same way, you can split do_lua in  2 version :

-- will report error in err
values, err = luaenv.Sandbox:new{x = 1, y = 2}:do_lua_safe("z = x + y")

-- will halt with proper error report
values = luaenv.Sandbox:new{x = 1, y = 2}:do_lua_fail("z = x + y")

There is different use of sandbox :
   - user entry :
      - must silently fail
      - must report unexpected value to user
   - configuration :
      - report error to user in production mode
      - fail in development mode with proper trace
   - meta programing
      - fail with trace
  ...

If each case get is own function it would make code self documented.  
And error would be easier to catch.
If some case aren't of general use, module can individually sub-class  
Sandbox to had them.

An other thing that can be clean by using an external module/Rocks :  
Logging.
It is passed down to luaenv and it isn't clear how other module handle  
it :
   - get one at instantiation ?
   - query one in sputnik global space ?

If you make a small logging rocks who would setup an application wide  
logger. It would clean code a lot. General use rocks can make require  
of it optional or simply test global variable (LOGGER ?) before using  
it.
Actual scheme isn't very constant and it's a bit cumbersome to pass a  
logger reference all the way down.

- pierre