Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dicej opened this issue Jul 8, 2024 · 3 comments
Open

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

dicej opened this issue Jul 8, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@dicej
Copy link
Contributor

dicej commented Jul 8, 2024

I was surprised to find that preview2-shim gives guests access to the entire host filesystem by default:

_addPreopen("/", isWindows ? "//" : "/");
. 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
Copy link
Collaborator

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
Copy link
Contributor Author

dicej commented Jul 8, 2024

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
Copy link
Collaborator

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

@guybedford guybedford added the enhancement New feature or request label Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants