src,permission: emit dc messages from C++ and use --permission-audit

[RafaelGSS]

This PR supersedes #60578.

src,permission: add --permission-audit

Add --permission-audit flag that enables the permission model in
warning-only mode. Instead of throwing ERR_ACCESS_DENIED, it emits
a message via diagnostics channel and allows the operation to
continue.

Publish permission check results to per-scope diagnostics channels
(e.g., node:permission-model:fs) so users can observe permission
decisions at runtime via diagnostics_channel.

Refs: https://github.com/nodejs/node/issues/59935

src: add C++ support for diagnostics channels

Add a C++ API for diagnostics channels that allows native code to check
for subscribers and publish messages without unnecessary JS boundary
crossings. Uses a shared AliasedUint32Array buffer between C++ and JS
to track subscriber counts per channel, enabling a fast inline check
(HasSubscribers) that reads the buffer directly.

PTAL @joyeecheung @Qard

[nodejs-github-bot]

Review requested:

• @nodejs/config
• @nodejs/gyp
• @nodejs/security-wg
• @nodejs/startup

[Qard]

Very cool! Not going to block on it, but it would be ideal if we could have a more direct ObjectWrap pattern to link native channels to their JS counterpart and do publishes more directly rather than through this lookup table and callback doing a channel lookup on every publish.

One thing that may need some additional thought either way is what to do if a publish call happens at a point where it's not valid to call into JS at that exact time. What do we do in that situation? Panic? Schedule for next tick?

[Qard]

Not a huge fan of needing to call dc.channel(...) within the publish hot-path.

Was there some reason you didn't go for just having the C++ Channel type use ObjectWrap::Wrap(...) to wrap the actual channel object itself? I know we might not be able to do so immediately as the C++ channels might be initialized before we can actually get into JS, but we can late-bind, right?

Perhaps rather than a setPublishCallback we could have something like:

dc_binding.linkNativeChannel((name) => {
  return dc.channel(name);
});

When that is first called it'd immediately wrap all not-yet-wrapped native channels around their JS equivalent and then store the callback to do so for any future native channels.

[RafaelGSS]

I guess we could check if there are pending when linkNativeChannel is called. Pushing a commit shortly.

The reason I didn't use the ObjectWrap was due to a much larger refactor that would be necessary on diagnostics_channel js, and I was afraid of breaking/slowing the current status quo.

[RafaelGSS]

PTAL 127b87a

[Qard]

What about it would need refactoring? As long as the C++ side only covers publishing into JS it should only ever need to wrap a C++ type around the JS type when the C++ actually wants to publish to it. We can just wrap lazily, only doing so when an actual C++ channel interface is requested for a particular channel name. We can negotiate that through the linkNativeChannel by only calling that for channels that need to locate their JS counterpart.

If we want deeper integration in the future we can always change that to share the channel map with the C++ side in the future, but I'm not sure if we'll actually need that unless someone has a use case for the native side subscribing to the JS side, but then we have some more complicated things to figure out anyway, like message serialization.

[Qard]

cc @bengl You may also have opinions on the diagnostics_channel implementation in here.

[codecov]

Codecov Report

❌ Patch coverage is 80.62284% with 56 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.71%. Comparing base (4a13a62) to head (81a476a).
⚠️ Report is 77 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_diagnostics_channel.cc	81.86%	10 Missing and 23 partials ⚠️
src/permission/permission.cc	76.11%	8 Missing and 8 partials ⚠️
src/env.cc	0.00%	2 Missing and 2 partials ⚠️
src/node_diagnostics_channel.h	57.14%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61869      +/-   ##
==========================================
- Coverage   89.76%   89.71%   -0.05%     
==========================================
  Files         675      676       +1     
  Lines      204674   205883    +1209     
  Branches    39330    39462     +132     
==========================================
+ Hits       183716   184716    +1000     
- Misses      13235    13322      +87     
- Partials     7723     7845     +122     

Files with missing lines	Coverage Δ
lib/diagnostics_channel.js	99.12% <100.00%> (+0.02%)	⬆️
lib/internal/process/pre_execution.js	96.93% <100.00%> (+0.96%)	⬆️
src/node_binding.cc	82.74% <ø> (ø)
src/node_external_reference.h	100.00% <ø> (ø)
src/node_options.cc	76.40% <100.00%> (+0.12%)	⬆️
src/node_options.h	97.94% <100.00%> (+0.05%)	⬆️
src/node_snapshotable.cc	73.01% <ø> (+0.07%)	⬆️
src/permission/permission.h	100.00% <100.00%> (+20.00%)	⬆️
src/node_diagnostics_channel.h	57.14% <57.14%> (ø)
src/env.cc	84.80% <0.00%> (-0.44%)	⬇️
... and 2 more

... and 153 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[RafaelGSS]

PTAL @Qard

[nodejs-github-bot]

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

[nodejs-github-bot]

Landed in 430ff43...a8eb690