4 ms·
Imho those permission systems are still too rudimentary and too non-automated. Instead of CLI flags I would like to see permission enforced at dependency bounda
by silverwind 3y ago
Imho those permission systems are still too rudimentary and too non-automated. Instead of CLI flags I would like to see permission enforced at dependency boundaries, e.g.
import foo from 'foo' with {permissions: ['fs', 'net']}
- throwitaway1123 3y agoEnforcing permissions at dependency boundaries would be the ultimate goal, but trying to separate first-party code from third-party code within the same thread is a herculean task (if I pass a callback to a dependency, which permissions does it run with for example), and you can't really lean on JS engines to do the heavy lifting, because they weren't designed with that threat model in mind. The best you can do currently is run your dependencies in a Worker, and enforce permissions programmatically for the worker [1]: For example: new Worker(import.meta.resolve('./worker.js'), { type: 'module', deno: { permissions: { net: ['news.ycombinator.com'], read: [new URL('./sqlite.db', import.meta.url)], write: false, }, }, }) This isn't perfect by any means, and you shouldn't rely on it like a silver bullet, but if given the choice I'd rather have permissions in my security toolbox. [1] https://docs.deno.com/runtime/manual/runtime/workers#specifying-worker-permissions https://docs.deno.com/runtime/manual/runtime/workers#specify...