[leeoniya]

do permissions in deno propagate to all dependencies recursively? like, if i grant filesystem access to a top-level script, did all its imports just inherit that permission, too?

if so, i can see this type of system being mostly worthless.

[etaioinshrdlu]

Yes... it would actually be quiet amazing to have different libraries in different sandboxes with defined communication channels.

The browser actually does something quite a bit like this with iframes. Iframes are sandboxed and can only communicate through postMessage. There's more to it but at a simple level it looks like this.

Chrome nowadays even runs iframes in a separate process! Finally... https://www.chromium.org/developers/design-documents/oop-ifr...

This is actually quite impressive because it presents a decent illusion to JS that all frames are running under the same thread.

[memexy]

You could implement this by fine grained imports and subprocess execution. Node.js actually has a very nice sub-process communication API: https://nodejs.org/api/child_process.html#child_process_subp....

At some point I remember writing some gpg wrappers with Node.js and I remember the subprocess API being one of the more pleasant ones to work with. In the case of more stringent Deno process sandboxing, the parent process would spawn another Deno process with a smaller set of capabilities.

[Pozzuh]

Deno uses the web standard Worker API to implement sub processes. They are also working on fine-grained permissions for these workers [1].

[1] https://github.com/denoland/deno/issues/4867

[memexy]

Good to know and even better than my proposed solution then. If the language supports it directly then there is no need to write sub-process shims for managing permissions.

[mkj]

Doesn't seem to limit them?

Using something like Caja https://developers.google.com/caja/docs/about might work, using object capabilities rather than ambient privileges. Not sure if Deno helps at all there though.