feat(sandbox): add -Zsandbox unstable flag #66
+85
−22
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
This is an experiment for rust-lang/rust-project-goals#108.
An unstable
[sandbox]
config table is added behind the-Zsandbox
unstable flag:sandbox.runner
: Target platform sandboxed build scripts built forsandbox.target
: Runner that executes artifacts of build scriptsHere is an example
.cargo/config.toml
:Also an example
main.rs
:What did we achieve in this experiment?
As you can see, we can easily swap to any sandbox runner with a custom target.
We use
wasm32-wasip1
above as an example,as it is the one with smaller footprint, very cross-platform, and pretty popular in the Rust community.
However, it turns out that `wasm32-wasip1 doesn't support POSIX process spawning.
Use cases of process spawning in build scripts are essential, such as
pkg-config
to find system libraries.cargo metadata
to get crate metadata.git
.According to the design axioms,
Restrcting process spawning is the top one axiom.
We made that with
wasm32-wasip1
,but have no way to opt-out.
This contradicts to the "ensuring
-sys
crates be built" axiom.As a result, it is unlikely to use
wasm32-wasip1
as a default sandbox environment with this experiment.Other possibilities
Have talked to some other folks, there are some potential route we could take if we chose wasi as a default sandbox environment.
The offical
build-rs
crate to the rescueThe Cargo team recently adopted the
build-rs
crate.It is going to be the official crate providing API for writing build scripts.
We could take the advantage of it, telling everyone instead of using
std::process::Command
, use something likebuild_rs::Command
. So that Cargo could have a full control over how a build script spawning processes.While it sounds ideal, this doesn't help the current situation because
build-rs
in build scripts may increase build time; people may refuse to use.A Cargo-flavored wasi standard library
There was a discussion in the GSoC "sandboxed proc-macro with wasm" about shipping a custom verion of the standard library for sandboxed wasm. For Cargo's build script, we could potentially ship a
wasm32-wasi-cargo
target. The std in this custom target could intercept anyexec
call or process spawning. Then it calls back to the host process (which is Cargo in our case) to determine how to handle process execution. The host process could either reject, or run the external program and post back the result.This idea sounds pretty hacky and need more investigations of the communication mechanism between the host process and the wasm runtime. Perhaps via sockets, The WebAssembly Component Model, other host function call mechanism. There is also WASIX project which supprots
fork
/exec
though it is currently not a WASI standard not even a proposal.Continue with other more mature sandbox runtime choices
Since one of major design space is the user interafce of sandbox configuration,
we could leave off sandbox runtimes and explore more on the configuration side.
We could, for example, use docker or eBPF as a temporary default runtime, and explore how the configuration should look like.
We may want to take a look at the configuration of Cackle-rs as a starting point. By doing so, we wouldn't block on waiting for wasm runtime to being more mature.