Discussion: Basic capability-like structure using e.g. UUID

[kevinkassimo]

In discussion from Gitter, @j-f1 proposed using UUID or similar potentially unforgeable entity for accessing native resources.

I think if might be viable to implement something simpler yet might be easy to integrate to Deno as a first step: introducing APIs that allow a module to create a resource mapped by UUID and pass this resource to other modules. Since normal bindings does not have access to the module where certain op is invoked, we might place it on import.meta which has strong association to different modules.

Some API like the following:

// This is actually referring to a resource and that might be modified from any existing handle
class Capability implements Reader /* Writer Seeker Closer */ {
  uri: string;
  id: string;
  // ...
}

// Returns a new Capability, or existing one if already has.
// Potentially only exposed in the main module.
await import.meta.requestCap({
  type: 'file',
  perm: 'rw',
});

// All Capabilities for this module
import.meta.caps;

// Forward a Capability to another module
await import.meta.forwardCaps("./path/to/another/module", [myCap]);

On the Rust side we might be able to use the sent UUID as the ID in a table to find the corresponding resource.

This is a very crude design and might not be very useful (notice this design means so-called "Capability" is not revocable -- unless the underlying resource itself is closed), but I think it could serve as a starting point for more capability design and implementation related discussions.

(Notice that Deno.core.send is currently exposed publicly. If not (possibly hidden inside of a WeakMap) then other JS/TS side solutions might work)

[solson]

A capabilities system for modules would be great for Deno's security story. I'm going to be writing a lot of personal scripts with file read/write and network access, but the terminal colors script I import from a URL definitely shouldn't share any of that access!

There are some potentially interesting relevant discussions happening in this TC39 proposal.

[stale]

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