Hacker News Reader

Comment by z3t4 | Hacker News Reader

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.

View on HN

The creator of Node is currently working on a runtime to enable exactly that: https://deno.land

    deno --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 =)

You 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

On 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});

you 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.

Reply on news.ycombinator.com