libseed-list sandboxing and scoped include

[Jonatan Liljedahl <lijon kymatica com>]

Alan Knowles wrote:
> You can already to that
>
> var ctx = new imports.sandbox.Context; ctx.add_globals(); 
> ctx.eval('Seed.scoped_include(' + JSON.stringify(somefile) +');');

Or rather

var ctx = new imports.sandbox.Context;
ctx.add_globals();
ctx.eval("Seed.include('"+__script_path__+"/my_extensions.js')");

which is what I was already doing actually.

> or this might work...
>
> var ctx = new imports.sandbox.Context; ctx.add_globals(); 
> ctx.get_global_object().Seed.scoped_include.call( 
> ctx.get_global_object(), somefile );

I think the point with scoped_include() is to return the namespace 
(global object) of the included file. Same as doing the eval() stuff 
above in a new Context and returning the ctx.global.

I also tried this:

Seed.include.call(ctx.global, somefile);

But no.. The symbols in somefile doesn't get added to ctx.global nor to 
the current scope. They should be added simply to the current context, 
because the normal usage of Seed.include() would have this==Seed, so it 
is not using 'this' to get to the global object.

This almost worked for me:

    var lib = Seed.scoped_include(__script_path__+"/as_extensions.js");
    var g = ctx.global;
    for(var k in lib) if(lib.hasOwnProperty(k)) g[k]=lib[k];

But of course the prototype extensions wasn't copied, only the toplevel 
variables.

> or even use imports on them.

I think ctx.global.imports and ctx.global.Seed are the same objects as 
the toplevel this.imports and this.Seed. Also, imports uses an internal 
sandbox context so prototype extensions doesn't get leaked out from the 
module (which in this case is what I want).

> From what I remember though the Sandboxing is not 100% safe, I do
> remember importing files into a sandbox, that where also imported
> into the parent process, and the engine re-used the cached import,
> rather than re-importing. Leading to variables in the sandbox
> affecting the parent process. - It would probably be a good idea to
> do a test case on that.

I see, but sometimes that is exactly what I want, to just use the 
sandbox to have a global object under control but still use the cached 
modules both for performance and the fact that some modules might do 
some book-keeping or initialization.

But I think having a 100% isolated sandbox is not posible of you do 
ctx.add_globals(), since the added globals in effect adds a loop-hole 
out of the sandbox. If you need a sandbox for security reasons, you 
should add only selected globals.

Regards
/Jonatan

> Regards Alan
>
> --- On 18/Jun/2010, Jonatan Liljedahl wrote:
> > It would be nice if Seed.scoped_include() can take an optional
> > global obj as input, then one could prepare sandboxes with:
> >
> > ctx = new sandbox.Context; 
> > Seed.scoped_include(somefile,ctx.global);
> >
> > /Jonatan _______________________________________________ 
> > libseed-list mailing list libseed-list gnome org 
> > http://mail.gnome.org/mailman/listinfo/libseed-list
>
> _______________________________________________ libseed-list mailing
> list libseed-list gnome org 
> http://mail.gnome.org/mailman/listinfo/libseed-list