[Proposal] Configure permissions from deno.json

[vrugtehagel]

The issue

Deno's permission system is great, but personally, I find it difficult to use. One of the main issue I have with them is that they are very verbose; even simple commands become an unreadable soup of permission flags. And since they are typically defined in a task within a JSON file, it is not generally possible to neatly break the command over multiple lines to increase readability. Here's a task from in real-world Eleventy project I maintain:

deno run --no-prompt --allow-env --allow-sys=cpus --allow-run=esbuild --allow-net=0.0.0.0:7337 --allow-read --allow-write=_site npm:@11ty/eleventy --serve --port=7337 --loader=esm

Alternatively, we can collapse flags to their single-character variants and we get

deno run --no-prompt -ER -S=cpus --allow-run -N=0.0.0.0:7337 -W=_site npm:@11ty/eleventy --serve --port=7337 --loader=esm

which, yes, is shorter, but now maintainers need to remember what each of these characters mean to understand these permissions (and the command still is quite lengthy). The verbosity makes it very attractive to just use -A (--allow-all), because it transforms the command into a much more succinct and readable

deno run -A npm:@11ty/eleventy --serve --port=7337 --loader=esm

Of course, readability is not a good reason to ignore security. But I think we can have both.

Proposed solution

The suggested solution here is a new "permissions" key in Deno config files. deno run already reads this config file (either automatically or through an explicitly provided flag) for things like TypeScript compiler options. Adding permissions to this config file would be a massive boost to readability; the above could be rewritten as

{
  "permissions": {
    "noPrompt": true,
    "allow": {
      "env": true,
      "sys": ["cpus"],
      "run": ["esbuild"],
      "net": ["0.0.0.0:7337"],
      "read": true,
      "write": "_site"
    }
  },
  "tasks": {
    "serve": "deno run npm:@11ty/eleventy --serve --port=7337 --loader=esm"
  },
  // …
}

This would make it much easier to see at a glance what permissions the project needs; even if they are just the sane defaults for the project (where individual commands may still overwrite these permissions with a flag).

Note that the object structure here is not particularly important; a flattened object, with keys matching the flags (e.g. "allowEnv" rather than a nested "env" in an "allow" object) would provide more-or-less the same value, and so would other sane choices for the structure.

[dsherret]

Also see #27483