3 ms·
Yeh, you could spawn new processes with different access levels, but it might add too much complexity to the app. It would be cool if we could require modules l
by z3t4 7y ago
Yeh, you could spawn new processes with different access levels, but it might add too much complexity to the app.
It would be cool if we could require modules like this:
foo = require("excitingModule", {fs: true, net: true, os: true});
It wouldn't be that hard to implement either.
- fock 7y agoyou know the basic working principle of Linux-Namespaces? And Iirc the JS-intepreter is not spawning a subprocess with a communication pipe for each require? So good luck with your "easy implementation" - you could also just create a standard library/make PRs removing unnecessary cruft from existing high-level packages. And if you think creating an interpreter in the interpreter is the solution, I'm quite sure the thing will not be secure if it is a natural child of the JS ecosystem.
- lachenmayer 7y agoThe creator of Node is currently working on a runtime to enable exactly that: https://deno.land https://deno.land
- z3t4 7y agodeno --allow-net https://deno.land/std/examples/echo_server.ts This would be the same as running something with an unprivileged user: sudo -u otheruser node echo_server.js Deno however takes it to a whole new level by running server code directly from the web =)
- bartlomieju 7y agoYou can scope it further: deno --allow-net=0.0.0.0:8000 https://deno.land/std/examples/echo_server.ts Or even provide a list of addresses: deno --allow-net=0.0.0.0:8000,localhost https://deno.land/std/examples/echo_server.ts
- z3t4 7y agoOn Linux you can use namespaces ip netns exec networkname node script.js Still only on the entire app though, the idea was how to restrict single modules and their dependencies, not your whole app! Something like: const foo = requires("bar", {fs: true, net: "0.0.0.0:8000", os: true});