child_process: harden against prototype pollution

[LiviaMedeiros]

Improve robustness against something like

Object.assign(Object.prototype, {
  cwd: '/etc',
  uid: 82, // www-data
  execFile: '/bin/rm', // using rm to "spawn" modules
  execArgv: [ ... ],
  shell: '...',
  env: { ... },
  ...
});

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52685/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52697/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/52717/

[aduh95]

Not related to this PR, but I wonder if we should use { __proto__: options, shell: false } and let users decide if they want prototype pollution or not.

[LiviaMedeiros]

Wouldn't it make this object affected by subsequent mutations outside?
In fact, I wonder if we should use structuredClone() or at least make copies of object properties like .env to avoid race conditions if multiple fork()s are called with reused options.

[aduh95]

Wouldn't it make this object affected by subsequent mutations outside?

I guess it depends if we read the properties in the same tick or not (which I expect we do most of the time, but I haven't checked).

In fact, I wonder if we should use structuredClone()

That wouldn't help with inconsistency of our API: sometimes, we dismiss inherited properties, sometimes we don't. But it's clearly not a big deal as I don't think we ever received any bug report regarding that.

or at least make copies of object properties like .env to avoid race conditions if multiple fork()s are called with reused options.

but wouldn't folks expect the same env to be shared if they supply the same object? The fact that no one complains makes me think we're overthinking it 😅

[nodejs-github-bot]

Landed in 6a88926