Tool for permission policy

[loynoir]

What is the problem this feature will solve?

https://nodejs.org/dist/latest-v20.x/docs/api/permissions.html

Interesting feature.

But seems lack of tool to generate policy.json from node_modules.

What is the feature you are proposing to solve the problem?

Provide tool generate policy.json from node_modules, within nodejs/node, or under org nodejs.

What alternatives have you considered?

• or generate-or-update-policy-json-after-test-ok

$ node --generate-or-update-policy-json-after-test-ok=/path/to/output/policy.json ./test.js

• or

$ export GENERATE_OR_UPDATE_POLICY_JSON=/path/to/output/policy.json
$ node ./a.js
$ node ./b.js
$ # /path/to/output/policy.json now is policy.json for ./a.js and ./b.js

[bnoordhuis]

Provide tool generate policy.json from node_modules

Can you elaborate how that should work exactly?

[loynoir]

Quote #48591 (comment)

node does not currently support import maps and import maps don't support the proper values for things like delegation to the loader

To me, permission policy.json seems like the nodejs version of importmap, but different interface to suite nodejs need.

Can you elaborate how that should work exactly?

So, just like a tool generate importmap from node_modules but for nodejs.

[bnoordhuis]

@bmeck you should chime in here

[bmeck]

I've looked into this in a variety of avenues ; the first iteration was an out of band tool like https://github.com/bmeck/node-policy (5 years ago 😅); then a prompt based system like a mobile app/browser permissions model. My hesitancy with generating after a run using coverage is a a few fold:

1. If this is done after malware runs, its... too late
2. If an application is updated and its test / coverage doesn't cover some specific case it could take down a production server. E.G. adding a src/foo.mjs but not having a test cover it. I think some level of tooling is needed to not just mark what is going to be an absolute error, but what appears like it should warn instead of error (right now policies only have global flags instead of per incident settings for this).
3. These permissions can differ for different environments (.env.prod / .env.local come to mind).

I think there are problems with the other approaches mentioned above however:

1. an out of band tool/workflow w/o running code requires complex heuristic static analysis (including potentially ENV support). bundlers have made this work so perhaps that should be the avenue to look at but at that point bundling into a single file and setting permissions would be simpler than an out of band tool.
2. prompts cannot be done on non-interactive situations / often are just accepted. The first run needs to be bootstrapped somehow else it gets a lot of prompting per experimentation in https://twitter.com/bradleymeck/status/1295793236066304000 which ended suffering to the dread Accept All as the only sane path forward. This could be mitigated if there was a standard to declare needed permissions in a static way like package.json for bootstrapping that could be summarized all at once at package install time rather than iterative prompting. We ended up taking this route in socket npm's wrapper but it wouldn't work w/ runtime iteration where you stop the world while waiting for approval.

I like the overall idea though, just never got encouraging feedback from any of my efforts a few years back so think renewed interest may be needed to actually get it off the ground.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.