-
Notifications
You must be signed in to change notification settings - Fork 62
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
Comments
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:
How does that sound to you? |
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. |
Great, I'll mark this as an enhancement, happy to try and hack on some workflows here further. |
I was surprised to find that
preview2-shim
gives guests access to the entire host filesystem by default:jco/packages/preview2-shim/lib/nodejs/filesystem.js
Line 600 in 304aa9d
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 thewasmtime-wasi
handles such things.The text was updated successfully, but these errors were encountered: