Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib: be robust when process global is clobbered #10135

Closed
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 15 additions & 6 deletions lib/internal/bootstrap_node.js
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,13 @@

'use strict';

(function(process) {
(function(global, process) {

function startup(global, process) {
// Expose the global object as a property on itself
// (Allows you to set stuff on `global` from anywhere in JavaScript.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please give an example? I don't follow.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't write this comment, I only moved it around. I can remove it if you want.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, it came from C++ code. I think we can remove this now.

global.global = global;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this also be non-writable?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh not yet. Thanks. I'll read that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(it should be non-enumerable though)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the record: this is just the global->Set(..., global) from node.cc moved to JS land.


function startup() {
const EventEmitter = NativeModule.require('events');
process._eventsCount = 0;

Expand Down Expand Up @@ -196,7 +200,12 @@
enumerable: false,
configurable: true
});
global.process = process;
Object.defineProperty(global, 'process', {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is needed / warranted. If someone wants to delete global.process it should still work. Natives having proper refs to process is already achieved via the wrapper hange.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was requested by @sam-github in #10135 (comment).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I as well as @ljharb disagree with this change.

Copy link
Member

@bmeck bmeck Jan 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

basically, if we set this precedent I would be much more comfortable locking down all things that core could depend on, either by adding them to a closure ala https://github.com/bmeck/node/tree/no-globals or by freezing them on the global. There are many of these globals that break npm modules in the wild if they are overwritten. I do not see process as exceptionally high use vs Error for example. I am against freezing them on the global for polyfill reasons.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there many? https://nodejs.org/api/globals.html documents only a bit more than a dozen "globals", and half of them aren't global, they are module-scoped variables. Perhaps all the "globals" should be module-scoped variables? So that its impossible to mess with them globally?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does not include prototype hijacking protection, thats raw global refs.

value: process,
writable: false,
enumerable: true,
configurable: true
});
const util = NativeModule.require('util');

// Deprecate GLOBAL and root
Expand Down Expand Up @@ -504,7 +513,7 @@
};

NativeModule.wrapper = [
'(function (exports, require, module, __filename, __dirname) { ',
'(function (exports, require, module, __filename, process) { ',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its confusing that there are two wrappers now, and they are different.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Am I reading this correctly, internal modules no longer have __dirname? I guess it would be too big a change to have process be injected as a module argument for all modules, internal and external, rather than be in globals? Ben, was there discussion about whether node's "globals" should be true-global or module locals? module/exports/__filename/__dirname have meaning only in local context, but why did require() become a local?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its confusing that there are two wrappers now, and they are different.

That's the price of progress.

Am I reading this correctly, internal modules no longer have __dirname?

They never really did, it was always undefined because built-in modules don't live on disk.

I guess it would be too big a change to have process be injected as a module argument for all modules, internal and external, rather than be in globals?

I'm not against that per se but that's a bigger change and probably needs more discussion.

why did require() become a local?

I believe it always was. It sort of has to be because it works relative to the calling script.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed it knew its current module using some other mechanism, but that makes sense. Also about __dirname.

'\n});'
];

Expand All @@ -520,7 +529,7 @@
lineOffset: 0,
displayErrors: true
});
fn(this.exports, NativeModule.require, this, this.filename);
fn(this.exports, NativeModule.require, this, this.filename, process);

this.loaded = true;
} finally {
Expand All @@ -532,5 +541,5 @@
NativeModule._cache[this.id] = this;
};

startup();
startup(global, process);
});
11 changes: 9 additions & 2 deletions lib/module.js
Original file line number Diff line number Diff line change
Expand Up @@ -54,8 +54,15 @@ Module._extensions = {};
var modulePaths = [];
Module.globalPaths = [];

Module.wrapper = NativeModule.wrapper;
Module.wrap = NativeModule.wrap;
Module.wrapper = [
'(function (exports, require, module, __filename, __dirname) { ',
'\n});'
];

Module.wrap = function wrap(script) {
return Module.wrapper[0] + script + Module.wrapper[1];
};

Module._debug = util.debuglog('module');

// We use this alias for the preprocessor that filters it out
Expand Down
8 changes: 2 additions & 6 deletions src/node.cc
Original file line number Diff line number Diff line change
Expand Up @@ -3441,19 +3441,15 @@ void LoadEnvironment(Environment* env) {

env->SetMethod(env->process_object(), "_rawDebug", RawDebug);

// Expose the global object as a property on itself
// (Allows you to set stuff on `global` from anywhere in JavaScript.)
global->Set(FIXED_ONE_BYTE_STRING(env->isolate(), "global"), global);

// Now we call 'f' with the 'process' variable that we've built up with
// all our bindings. Inside bootstrap_node.js and internal/process we'll
// take care of assigning things to their places.

// We start the process this way in order to be more modular. Developers
// who do not like how bootstrap_node.js sets up the module system but do
// like Node's I/O bindings may want to replace 'f' with their own function.
Local<Value> arg = env->process_object();
f->Call(Null(env->isolate()), 1, &arg);
Local<Value> argv[] = { global, env->process_object() };
f->Call(Null(env->isolate()), arraysize(argv), argv);
}

static void PrintHelp() {
Expand Down
7 changes: 7 additions & 0 deletions test/parallel/test-process-clobber.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
/* eslint-disable no-global-assign */
'use strict';

require('../common');
const assert = require('assert');

assert.throws(() => process = null, /Cannot assign to read only property/);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should throw. Natives should be robust w/o relying on globals once startup finishes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The built-in libraries are, this checks that process is not assignable per the second commit.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that is appropriate to lock down.