在 Node.js 中为动态加载的模块更改全局 Scope

Question

Loading a module from a source dynamically:

var src="HERE GOES MY SOURCE"
var Module = module.constructor;
var m = new Module();
m._compile(src, 'a-path-that-does-not-exist');

Need to achieve following:

1. Pass some variables/functions so that they can be used inside the src script globally. Can set them in "m.foo", but want the script to use "foo" without using "module.foo". "global.foo" works, but see the point 2.
2. How to restrict the src script from accessing global scope?
3. How to restrict the src from loading other modules using require or other means.
4. How to restrict the src from running async operations?

Answer 1

All, I can think of is to wrap the script in its own function, kind of like nodejs already does for commonJS modules. This is the regular wrapper.

(function(exports, require, module, __filename, __dirname) {
// Module code actually lives in here
});

If you wrap that user code with your own wrapper and then when you call it to execute it, you can define your own values for require , module and any other semi-global symbols.

If you also put 'use strict'; as the very first line of your wrapper function (before any of the user code), then that will eliminate default assignment to the global object with just something like x = 4 because that will be an error without explicitly defining x first. If you then also make your own global object and pass it as an argument, that can keep anyone from assigning to the real global object. I don't think you can prevent implicit read access to pre-existing globals.

So, your wrapper could look like this:

(function(exports, require, module, __filename, __dirname, global) {
     'use strict';
     // insert user code here before evaluating it with eval()
     // and getting the function which you can then call and pass the desired arguments
});

Then, when you call this function, you pass it the values you want to for all the arguments (something other than the real ones).

---

Note, it's hard to tell how leak-proof this type of scheme really is. Any real security should likely be run in a resource restricted VM.

---

Another idea, you could run in a Worker Thread which has it's own virgin set of globals. So, you do all of the above and run it in a Worker Thread.

---

Addressing your questions in comments:

Does the 'use strict'; need to go inside the wrapper function or outside?

It needs to be the first line of code inside the wrapper function, right before where you insert the user code. The idea is to force that function scope (where the user code lives) inside that wrapper to be in strict mode to limit some of the things it can do.

Could you explain the "I don't think you can prevent implicit read access to pre-existing globals."? If i provide my own object as global, how can the inner script access preexisting globals?

Any code, even strict mode code can access pre-existing globals without the global prefix. While you can prevent the code from creating new globals by shadowing it with your own global in the wrapper function arguments and by forcing it into strict mode, you can't prevent strict mode code from reading existing globals because they can do so without the global prefix. So, if there's a pre-existing global called "foo", then existing code can reference that like:

 console.log(foo);

or

 foo = 12;

If there is no foo in a closer scope, the interpreter will find the foo on the global object and use that.

Note that strict mode prevents the automatic creation of a new global with something like:

 greeting = "happy birthday"

Could you elaborate more no "resource restricted VM"?

I was talking about real hardware/OS level VMs that allow you to fully control what resources a process may use (disk access, sockets, memory, hardware, etc...). It's essentially a virtual computer environment separate from any other VMs on the same system. This is a more rigorous level of control.

WorkerThread is a very interesting concept. will take a look? My understanding was that WorkerThreads provide memory isolation and the only way to share data is by sending messages (effectively creating copies)?

Yes, Worker Threads provide pretty good isolation as they start up a whole new JS engine and have their own globals. They can shared ArrayBuffers in certain ways (if you choose to do that), but normal JS variables are not accessible across thread boundaries. They would normally communicate via messaging (which is automatically synchronized through the event queue), but you could also communicate via sockets if you wanted.