Permission Model - Roadmap

[RafaelGSS]

As discussed earlier in nodejs/node#44004 and #791, the purpose of this issue is to establish a comprehensive roadmap for the Permission Model. I will be proceeding with the following list of action items, and in cases where further discussion is necessary, I will initiate a separate issue for each item.

• Permission Model adoption on package managers (Permission Model adoption from Package Managers #1300)
• Support path.resolve in C++ side to avoid possiblyTransformPath lib,src,permission: port path.resolve to C++ node#50758
  • Support relative paths lib,src,permission: port path.resolve to C++ node#50758
• Read permissions from a config file (policy.json) - Load permission settings from config files #1074
• Throw access denied asynchronously for async APIs. (src,permission: throw async errors on async APIs node#52730)

  fs.readFile('restricted-file.md', (error) => {
    // error is ERR_ACCESS_DENIED
  })

• Allow Addons src,permission: add --allow-addon flag node#51183

New permissions

• net

cc: @nodejs/tsc for awareness

[BrunoBernardino]

Sorry if this is intrusive and not productive, I didn't see a rationale for choosing a new file (permissions.json) vs an existing file with a new property (package.json:permissions), is there one available somewhere for me to read?

[RafaelGSS]

This is a good discussion, @BrunoBernardino. We'll certainly evaluate that when working on this implementation. Likely, the outcome will be from the discussion with package managers.

[bmeck]

Is there any reason to separate policy integrity/redirects from permissions, would be ideal if they could share the same file. Particularly if eventual possibility of more granular per resource (URL) configuration.

[RafaelGSS]

Is there any reason to separate policy integrity/redirects from permissions, would be ideal if they could share the same file. Particularly if eventual possibility of more granular per resource (URL) configuration.

My only concern is the fact policies are experimental, so the permissions will be blocked to get out of the experimental until policies are stable. Other than that, sounds good to me.

[aduh95]

My only concern is the fact policies are experimental, so the permissions will be blocked to get out of the experimental until policies are stable. Other than that, sounds good to me.

One could argue that it's another reason for using policies, so both can graduate to stable faster ;)

[bmeck]

Using the same file isn't really related to blocking advancement also name of the file isn't important ( can already use policies with a file called permissions.json)

…

On Fri, Mar 3, 2023, 6:17 AM Antoine du Hamel ***@***.***> wrote: My only concern is the fact policies are experimental, so the permissions will be blocked to get out of the experimental until policies are stable. Other than that, sounds good to me. One could argue that it's another reason for using policies, so both can graduate to stable faster ;) — Reply to this email directly, view it on GitHub <#898 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJI5W6WL3VK4MGJDJBO3W2HOMBANCNFSM6AAAAAAVM2H4QQ> . You are receiving this because you commented.Message ID: ***@***.***>

[wesbos]

Just gave this a run through, very excited to see this going through. Just a few notes from an outsider / end user. I'm not up to speed on everything so, please take with a grain of salt!

1. a separate file for permissions will be groaned at. Everyone has config fatigue - putting it in package.json is ideal for me.
2. relative paths via the CLI - I'm not sure if there is a technical hurdle here, but this would be really nice, especially for all the random npx scripts people have you running.
3. Prompting for access would be great - similar to how Deno does it. this way you can run a script, and be prompted to see which files need to be read/written etc..