Permission meta-data manifest file

[rsp]

Once in a while a proposal for permissions file for Deno is suggested.
Sometimes it's strictly for permissions like here and sometimes it's more general like the comprehensive meta-data file in #3179.

This issue is to track info about similar systems if the idea of permission files come up in the future.

(For running complex Deno applications in the future it may be useful to be able to have single file that can be inspected and used instead of multiple command-line switches. Also, a similar format to express by the program the need for permissions to avoid issues described in #3655 would be useful and it might use a format similar to that for granting the permissions by the user.)

There are some existing systems that use JSON or YAML files with the same purpose, some use command-line switches. Maybe some of those solutions can serve as an inspiration for Deno (mainly how the permissions are defined, but maybe also how they work).

CloudABI - https://cloudabi.org/
A capability-based runtime environment for running untrusted native code without containers.
Supports C, C++, Python, Rust (Node.js coming soon - could it support Deno too?)
It uses YAML files to define permissions.
See:
https://github.com/NuxiNL/cloudabi#capability-based-security

Fuchsia - https://fuchsia.dev/
https://en.wikipedia.org/wiki/Google_Fuchsia
An operating system based on capabilities.
It uses JSON files to define permissions in component manifests
(CML - component manifest language - with a JSON Schema)
See:
https://fuchsia.dev/fuchsia-src/concepts/components/capabilities
https://fuchsia.dev/fuchsia-src/concepts/components/component_manifests

WASI - https://wasi.dev/
The WebAssembly System Interface
Since Deno can run WebAssembly, it might me useful to look into it.
See:
https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-capabilities.md
It doesn't define how to describe permissions, implementations like Wasmtime do, see below.

Wasmtime - https://wasmtime.dev/
A runtime for WASM with WASI support.
It uses command line switches like --dir=. and --mapdir=/tmp::/var/tmp to give permissions to the executed program.
See:
https://github.com/bytecodealliance/wasmtime/blob/master/docs/WASI-tutorial.md

Capsicum - https://www.cl.cam.ac.uk/research/security/capsicum/
an OS capability and sandbox framework for FreeBSD and Linux, extension to the POSIX API, it is quoted as one of the inspirations for WASI.
https://www.usenix.org/legacy/events/sec10/tech/full_papers/Watson.pdf

Related issues:

• Permissions on a module-level Permissions on a module-level #171
• Capability-based security model Capability-based security model #378
• Sandbox mode for external scripts Sandbox mode for external scripts #1639
• Per-import permissions? Per-import permissions? #1860
• Capabilities of process Capabilities of process #1862
• deno eval deno eval #2081 (some comments in that issue)
• proposal: support a comprehensive meta-data file proposal: support a comprehensive meta-data file #3179
• Permissions per modules with importmap like configuration Permissions per modules with importmap like configuration #3397
• List all required permissions at once List all required permissions at once #3655

[rsp]

Relevant wasmtime/WASI issues with an interesting discussion on the permission granularity:

• Capabilities granularity too low Capabilities granularity too low bytecodealliance/wasmtime#90 (start of the discussion)
• Capabilities granularity too low Capabilities granularity too low WebAssembly/WASI#1 (continuation here)

It may be useful to keep track of where WASI is going in regards to the permissions granularity and how to define them as sets etc.

[brandonkal]

Not a fan of having a seperate "manifest" file that sets things like permissions.
Let's just put this in the code.
Either require it in a standard JSDoc file-level comment:

/**
 * @file template.ts
 * @description Templates YAML and applies Terraform as required.
 * @copyright 2020 Brandon Kalinowski
 * @license MIT
 * @permissions --allow-read
 * @lockfile ./lock.json
 */

Or make it an API:

/**
 * @file template.ts
 * @description Templates YAML and applies Terraform as required.
 * @copyright 2020 Brandon Kalinowski
 * @license MIT
 */
Deno.requirePermissions({ ... })

I prefer the former because it can be statically determined without execution.

It's also quite a nice DX for the user:

1. import third-party module.
2. Click to go to that module's definition.
3. Look at permissions block.

The CLI can easily do something similar.

1. Fetch files as required by imports
2. Look at permissions blocks and sum them up.
3. Display to user:

This program would like to:
Read filesystem. Requested by module: template.ts
Is that okay: [N]/y:

I'd like to avoid crawling the filesystem for config files as much as possible.

[jsejcksn]

I like @brandonkal's suggestion. But what about modules with multiple exports and each one has different permission requirements?

Here's an imaginary YAML permissions example for a module repo:

deps.ts:
  export:
    readFileStr:
      read: true
    writeFileStr:
      write: true
mod.ts:
  export:
    readText:
      read: true
    writeText:
      write: true
test.ts:
  script:
    net:
      - github.com
      - deno.land
    read: true
    write: true

where each script can have two keys

• export holding each export with its required permissions
• script holding required permissions to import/run the script/module itself

Note: It's just an imaginary idea to use as an example. I'm not suggesting this format or YAML format.

I'd like to avoid crawling the filesystem for config files as much as possible.

I agree with this, and I wonder if there's a way to accomodate more explicit and granular permission requirements without a permissions config file.

[MarkTiedemann]

For running complex Deno applications in the future it may be useful to be able to have single file that can be inspected and used instead of multiple command-line switches.

I don't think this is a good argument since you can put your command, including all switches, into a shell script, batch file, Makefile or similar executable file in order for them to be "inspectable".

[jsejcksn]

a shell script, batch file, Makefile or similar

The problem with that is that it's not a single, cross-platform format.

There have been efforts to help with this. Ref: https://github.com/BentoumiTech/denox

[MarkTiedemann]

There's already a ton of cross-platform task runners. Makefiles are cross-platform, too, by the way.

Frankly, I don't think that YAML...

scripts:
  start:
    file: main.ts
    deno_options:
      allow-net: example.com

...is any better than Make.

start:
	deno run --allow-net=example.com main.ts 

In fact, YAML is far less powerful as far as the language is concerned (no variables, control-flow, etc.)... And, at least to me, in this case, it kind of obfuscates the commands that will be executed.

That being said, I'm not against improved permissions nor manifest files. I just don't think that "inspectability" is a good argument for creating a meta data file in this case.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[jsejcksn]

Not stale

[ArcticLight]

I just wanted to drop by and say that this was one of the first things that bothered me when I tried to switch a project over to Deno, and I was surprised that a solution wasn't already baked-in to the CLI for this.

Responding to:

There's already a ton of cross-platform task runners. Makefiles are cross-platform, too, by the way.

Frankly, I don't think that YAML...

scripts:
  start:
    file: main.ts
    deno_options:
      allow-net: example.com

...is any better than Make.

start:
	deno run --allow-net=example.com main.ts 

While I totally get that I could put a Deno command-line into a Makefile or a shell-script, it's somewhat important (to me, at least) that whatever the solution is, that it work out-of-the-box without other tools. Make might be cross-platform, but in a project with multiple maintainers, becomes "yet-another-dependency" that's needed, along with Deno.

It's also not always going to be clear what permissions are going to be, or how they are applied across projects if that were the case. As an example, in Node we might not like using package.json, at least everyone knows that they can look at package.json to see what scripts are in there. If some projects written using Deno start making use of Make and some use shell scripts and some use denox and some use <insert-here> that's not great. It would be nice if, whatever solution there is to this problem, it was builtin and came standard. It's related to inspectability, in that sense, because human-inspection is one thing ("Hey! This project has a makefile, I'll just go look for the --allow flags in there") but machine-inspection is a completely different thing, that a manifest, API, or JSDoc-based solution could address (i.e. writing a program that can inspect the current module + its dependencies for required permissions)

Personally, I like the API approach (the standard request/query permissions API that just recently came out could help with this use a lot), and I also like the manifest approach (A Deno project.toml file? YAML? Something like that). I think those are both good options.

[crowlKats]

A task runner has been implemented, and all issues besides #378 have been addressed, so am going to close this in favour of #12763.