Restrict unnecessary Deno permissions

[bartlomieju]

Looking at the action script I found:

flat/src/main.ts

Line 44 in 1c5bd95

`deno run -q -A --unstable ${config.postprocess} ${filename}`

Deno is run with -A flag which enables all permissions; it's probably not a big deal, but it seems that permissions could be restricted a bit to --allow-read, --allow-write, --allow-net and --allow-env; ie. disable ability to load native plugins, HR timing and spawning subprocesses.

[irealva]

It's a good point and we went back and forth on this, but ultimately we wanted to make the action permissive rather than restrictive.

There are some use cases out there we knew we wouldn't be able to predict. For example, someone already found a way to create a postprocessing script that incorporates Python. This was only possible because they spawned a subprocess with the --allow-run flag.

[bartlomieju]

There are some use cases out there we knew we wouldn't be able to predict. For example, someone already found a way to create a postprocessing script that incorporates Python. This was only possible because they spawned a subprocess with the --allow-run flag.

Interesting! I could see the use for HR timing as well, though I'd still suggest disabling native plugins for now, as they are quite unstable at the moment.

Great to see you chose Deno!

[irealva]

@idan thoughts?

By the way Deno is 🔥🔥 AWESOME 🔥🔥 to use. Really enjoyed using it for this project.

[idan]

@bartlomieju fair! Thank you for reaching out :) As Irene said, Deno is dope, and we love it. We're looking at more ways to use Deno to author actions; the current best practice of "use ncc to build your action before publishing" feels clunky.

@irealva I think we can get more specific in order to disallow plugins. Looking over the permissions docs, it's also possible to scope reads/writes to the repo checkout directory, which seems like a sensible guardrail to put in place? And maybe we also disable HR timers.

In practice, anyone who wants these capabilities is not blocked from doing so — either in their own action, or by forking ours and altering it. But guardrails are a good idea!

[bartlomieju]

@bartlomieju fair! Thank you for reaching out :) As Irene said, Deno is dope, and we love it. We're looking at more ways to use Deno to author actions; the current best practice of "use ncc to build your action before publishing" feels clunky.

Sure, happy to provide any assistance necessary, feel free to reach out at our discord.gg/deno

[irealva]

@bartlomieju quick clarifying question. If we remove the --allow-plugin flag but keep the --unstable flag does that mean people would still be able to run plugins?

[bartlomieju]

@bartlomieju quick clarifying question. If we remove the --allow-plugin flag but keep the --unstable flag does that mean people would still be able to run plugins?

@irealva no, they will still have access to unstable JavaScript APIs (because of --unstable flag), but trying to use native plugins will throw a PermissionDenied error because of missing --allow-plugin.

[irealva]

Fantastic, thank you!