Script.runInNewContext and global objects

[azatoth]

I notice when running scripts in a sandbox, there are no global
objects, i.e.

process.binding('evals').Script.runInNewContext('typeof process');

returns "undefined"

Even if now the script isn't executed in an new process, shouldn't at
least the global objects somehow be emulated?

This is related to an idea I had at
http://github.com/azatoth/nodeunit/commit/607f2a88cc5d949d23bfe29573da1c4ee4d718b5
where I never though of that the new context is 100% blank
True I could copy the relevant objects to the context before, but that
would break full enclosure I assume.

/Carl

[azatoth]

On Sep 25, 3:29 am, azatoth <azat...@gmail.com> wrote:
> I notice when running scripts in a sandbox, there are no global
> objects, i.e.
>
>  process.binding('evals').Script.runInNewContext('typeof process');
>
> returns "undefined"
>
> Even if now the script isn't executed in an new process, shouldn't at
> least the global objects somehow be emulated?
>

> This is related to an idea I had athttp://github.com/azatoth/nodeunit/commit/607f2a88cc5d949d23bfe29573d...

> where I never though of that the new context is 100% blank
> True I could copy the relevant objects to the context before, but that
> would break full enclosure I assume.
>
> /Carl

As I've not gotten any replies, perhaps I should extend the question/
query a bit.

First is the question if it's an feature or an bug that the context is
totally clean?

regardless of above I do think the best solution is some function to
create a basic context, for example "process.createContext()" or
"Script.createContext()".
An other possibility would be to clone the current context; though
that would include possibly unwanted objects.

For the global objects, "global" should off course be a empty (is it)
object.
process is a bugger, as it should possibly be a combination of current
process and/or a clean process; process.argv for example could either
be cloned, or be assigned per arguments to runInNexContext.

require should be new in my opinion, no copy here at all.
__filename should be set by argument to runInNexContext or Script
__dirname should be based on __filename and/or process.cwd()
module I can't say if it should be clean or not, probably it's realted
to process. (my knowledge of nodejs internals is limited)

/Carl

[Ricardo Tomasi]

If you had access to your current "global" objects, it wouldn't be a
new context.

On Sep 24, 10:29 pm, azatoth <azat...@gmail.com> wrote:
> I notice when running scripts in a sandbox, there are no global
> objects, i.e.
>
>  process.binding('evals').Script.runInNewContext('typeof process');
>
> returns "undefined"
>
> Even if now the script isn't executed in an new process, shouldn't at
> least the global objects somehow be emulated?
>

> This is related to an idea I had athttp://github.com/azatoth/nodeunit/commit/607f2a88cc5d949d23bfe29573d...

[Carl Fürstenberg]

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>

Where did I talk about by "current" global objects?
I had hope someone understood what I was referring to directly :(
I know I might be describing it badly, but if you read my reply, you
might get an extended view. we are talking about either create new,
emulate bare or clone current context.
Or can you tell me how to get the object "require" into the sandbox
without breaking sandbox-enclosure

/Carl

--
/Carl Fürstenberg <aza...@gmail.com>

[Carl Fürstenberg]

2010/9/26 Carl Fürstenberg <aza...@gmail.com>:

Divulging myself into the code now I see that the default context is
created in node.js; Perhaps a functions should be exported to recreate
a basic context?

--
/Carl Fürstenberg <aza...@gmail.com>

[Frank Grimm]

require, as well as several other internal module have their own state (in this case the module cache). You can expose them to your sandbox like every other variable from the calling context (e.g. {require: require} as the sandbox) but you'll have to use a seperate node instance as a child process to do it in a clean way.

best regards

2010/9/26 Carl Fürstenberg <aza...@gmail.com>

[Carl Fürstenberg]

On Sun, Sep 26, 2010 at 17:36, Frank Grimm <frank...@gmail.com> wrote:
> require, as well as several other internal module have their own state (in
> this case the module cache). You can expose them to your sandbox like every
> other variable from the calling context (e.g. {require: require} as the
> sandbox) but you'll have to use a seperate node instance as a child process
> to do it in a clean way.
> best regards

Yea, I was afraid that would be the one option. I'm gonna look into
some function to create as much as possible a fake context. I think a
lot can be reused from node.js, though I'm uncertain how to fake the
process object.

--
/Carl Fürstenberg <aza...@gmail.com>