Hacker News Reader

Comment by nikeee | Hacker News Reader

One important thing about containers is that they isolate the process and it can not access files it is not explicitly allowed to.

If I'm getting this right, WASI is basically just POSIX for WASM. This means that it does not provide some level of sandboxing that - for example - Deno has done. When running a Deno program, you have to actively allow network access or write access to the disk. It uses the built-in stuff from V8 for that.

Any idea why they did not include these kinds of permissions in the WASI standard? It seems like WASI was not designed to be run without some sandbox.

View on HN

That's how WASI is designed. You need to specifically mount a specific folder so it can be accessed by the module. The sockets support is not ready yet, that's the reason there's no specific limitation around networking.

For me, the most interesting part is the component-model. It's still a proposal, but it will allow developers to specify the permissions for other modules (libraries) a main Wasm module may use. With this, you can give access to a folder to a module and that module may call another one without giving them those permissions. In other ecosystems, any library used by the "main" logic gets the same permissions.

Why can't this be done with native code and sandboxing? Native code in a sandbox doesn't require a VM, and there is a big perf cost for wasm. Is it just for one extra layer of security?

You have to remember that WASM comes from web browsers. It is meant to be transferred across the web and run in a the browser on the target computer. It isn't very practical to compile everything to every architecture/os combination and serve the correct implementation.

Yeah but that's not the context of this use. Why are they taking something made for browsers (where architecture neutrality is important) and using it for sandboxing, instead of faster sandboxed (not VMed) native?

They are doing it for the same reason people keep ripping JS engines out of browsers: there has been so much work done to make them fast, harden the sandbox, and port them to different platforms. It's free real estate.

But couldn't that lead to a lot of permission errors?

If I have a complex program with a lot of dependencies.

What happens if one of the dependencies suddenly tries to write to `~/.local/dep_name/cache.raw` and I did not explicitly allow it to do so, since I didn't know it needs that location? In docker it would just create that folder in its own volume and the volume is deleted after the container is removed (if the volume is not named).

If I understood correctly from your comment, each WASI-runtime does not have a corresponding filesystem/volume.

But what does it do then? Will it simply crash?

No, you are not getting this right, and these permissions are built into the WASI standard.

Reply on news.ycombinator.com