permission: keep parent allowlist when Worker execArgv is empty

[yunshingng]

Description

Under --permission, creating a Worker with execArgv: [] could drop the parent's filesystem allowlist compared to a default Worker.

This change re-attaches parent Permission Model flags when execArgv is provided explicitly (including an empty array).

Test plan

• test/parallel/test-permission-worker-empty-execargv.js
• CI

cc @RafaelGSS

[nodejs-github-bot]

Review requested:

• @nodejs/security-wg

[RafaelGSS]

Thanks for the PR! However, I'm not sure this is something we should fix. The permission model doesn't inherit to worker threads by design.

--allow-child-process: if you grant it, you are trusting that code. We've been closing worker "bypass" reports as documented limitations for that reason.

Modifying execArgv is also a legit use case (giving the worker different flags than the parent), and this PR would remove that - we could argue that's a semver-major.

Even if we wanted inheritance, I don't think this approach works. Flags from NODE_OPTIONS don't show up in process.execArgv, so they wouldn't be copied at all. Repeated flags like --allow-fs-read=/a --allow-fs-read=/b only copy the first value (bug on this implementation)

So it gives the impression of inheritance without actually guaranteeing it, which IMO is worse than the current documented behavior. Doing this properly would mean enforcing it on the C++ side (intersection with the parent options) and it would likely be semver-major.

[yunshingng]

Thanks for the review!— agreed this should be treated as semver-major if we change the
behavior.

The intent of the current diff is not a patch-level fix and not a security
advisory fix. It’s a deliberate model change: when the parent has the
Permission Model enabled, a Worker’s permission-related grants must not
exceed the parent (C++ intersection after option parse), including the
execArgv: [] case.

That avoids the incomplete JS execArgv copying approach (NODE_OPTIONS,
repeated --allow-*, false sense of inheritance).

Please treat / label this PR as semver-major. I’m happy to adjust the
implementation or tests for the major-line process you prefer.

[yunshingng]

Some bug fixed , mostly done

[yunshingng]

re: "doesn't inherit to a worker thread" — that's actually inconsistent with what the worker_threads doc says. It describes execArgv itself as "By default, options are inherited from the parent thread," and separately says workers pick up the parent's CLI flags automatically as long as you don't touch execArgv. --allow-fs-read etc are CLI flags, so a default Worker inheriting them is literally the documented behavior on that page. not arguing to change the design here, just that the two docs contradict each other right now regardless of what we land on.

separately: omit execArgv and you keep the parent's allowlist, pass execArgv: [] and you lose it. that's backwards — the more explicit/careful-looking code ends up less safe than doing nothing. feels worth fixing on its own, independent of the bigger inheritance question.

also curious — did this specific execArgv: [] vs omitted case come up in the past "documented limitation" closures, or were those about full inheritance? if it's the latter I don't think that precedent covers this one as-is.