Deno: Add "fork" method to DenoPermissions

[bartlomieju]

To have Deno namespace in the worker, we'll want to provide a map of permissions worker should have. Worker's set of permissions mustn't escalate permissions of parent worker/Deno process.

To achieve that a method called fork should be added to DenoPermissions struct. fork would take as many parameters as there are fields on DenoPermissions and return new DenoPermissions instance after asserting that none of the permissions passed as arguments escalate parent permissions. If one tried to fork permissions with escalation then OpError::permission_denied should be returned with appropriate message indicating which permissions are being escalated.

Pseudo code:

impl DenoPermissions {
  fn fork(&self, allow_net: bool, net_whitelist: Vec<String>, ...) -> Result<DenoPermissions, OpError>;
}

This is an easy issue, only *_whitelist processing might be a bit complicated.

[bartlomieju]

Prerequisite for #3998

[humancalico]

@bartlomieju I'll work on this.

[jafern14]

@bartlomieju is this task still necessary? #3998 is closed. trying to figure out the value of this given that closed dep

[bartlomieju]

@jefern14 yes it's needed. Currently in worker permissions are inherited from process and we want to make them configurable. See #4867

[jafern14]

great thanks for the update. I'll be looking into this as well after work hours.

[jafern14]

@bartlomieju do you mind explaining a bit more of what you mean when you say "permissions escalation"? The way I'm looking at this having almost no knowledge of how this works is that a forked worker would inherit all the same permissions of it's parent. Your description makes me doubt my assumption so I'd like to understand prior implementing anything.

[bartlomieju]

@bartlomieju do you mind explaining a bit more of what you mean when you say "permissions escalation"? The way I'm looking at this having almost no knowledge of how this works is that a forked worker would inherit all the same permissions of it's parent. Your description makes me doubt my assumption so I'd like to understand prior implementing anything.

That's the case right now, when you create worker with Deno namespace it inherits parent process permissions. We want to make this option configurable so you can explicitly specify permissions for worker (eg. { read: ["/tmp"], net: true }). Escalation means that requested permissions for worker cannot be more permissive than main process permissions - ie. if you run program with only --allow-read flag the workers created cannot request that net and write are available to them.

[Axighi]

@bartlomieju I'm trying to work on this.

[humancalico]

@Axighi I already have an open PR. Although I do have to update it since DenoPermissions got renamed to Permissions

[ktfth]

The fork process just can work on Workers or have other scenarios?

[fabrizzioalco]

Hey, is this done? I want to contribute to this project

[bartlomieju]

Hi @fabrizzioalco, yes this issue was resolved in #5693. Try looking for issues tagged with "good first issue".