Prerequisite for #3998

@bartlomieju I'll work on this.

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

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

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

@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 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.

@bartlomieju I'm trying to work on this.

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

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