[preview2-shim] Consider giving guest no preopens by default

[dicej]

I was surprised to find that preview2-shim gives guests access to the entire host filesystem by default: https://github.com/bytecodealliance/jco/blob/304aa9dc7157e1f31b1695ea26e0c3dec3ecb6b6/packages/preview2-shim/lib/nodejs/filesystem.js#L600. That's the opposite of most other WASI host implementations, which provide no access to the host filesystem by default.

Is there some specific reason for that? If not, I'd recommend changing the default to no access and let the user or embedder specify the set of preopens using _setPreopens as desired.

More generally, I wonder if other host resources (network access, environment variables) should also be restricted by default and granted explicitly, similar to how e.g. wasmtime run and the wasmtime-wasi handles such things.

[guybedford]

I guess the reasoning is that this is the same default policy a Node.js application has so in the JS ecosystem it's kind of the expectation.

That is, if components are published to npm and loaded as libraries in JS, they should have the same capabilities as JS libraries, which in Node.js means everything.

But, if you are running in instantiation mode, where you're constructing a virtualization, then yes you definitely want all the sandboxing options.

So I'd suggest here that we:

• Have a better way of supporting instantiation mode for preview2-shim
• In that new workflow, support all the various sandboxing options as inputs

How does that sound to you?

[dicej]

That sounds fine to me. The main thing I'm looking for is an easy way to say: "Fully sandbox this component, giving it access only to what I've explicitly granted." Sounds like instantiation mode would fit the bill.

[guybedford]

Great, I'll mark this as an enhancement, happy to try and hack on some workflows here further.