wasi:exec
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 28/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- wasm
- Domain
- operating-systems
Research direction
Start by reviewing the existing WASI proposals for sockets, cli, and files, then compare the proposed exec and instantiate alternatives. Document a settled direction for component scope, permissions, subprocess I/O, lifecycle methods, and program sources; the issue is ready when those design questions have an agreed API.
Written by the indexing model from the issue text.
Description
I'd like to know if there's any appetite for a wasi:exec. My immediate use cases is to run existing multi-binary tools (compilers). It would also be nice to be able to sandbox a whole userspace on a local machine (so, run a shell, allow programs to start other programs) and/or to get a Docker-on-wasm flow working.
I think exec fits in nicely with the other wasi proposals (sockets, cli, files, etc.) and is I think the biggest missing feature in running wasi programs on a local machine (and perhaps maybe file locking?).
Some design questions to consider:
- Should exec run arbitrary programs, or just wasm components? I think from a security point of view, only wasm components would make sense.
- What permissions should a launched program run with? I would be tempted to say, default none, and there'd be some configuration object you can call grant functions on. That way the API is extensible for future runtime abilities.
- How should subprocesses interact? What happens with stdout, etc.? I guess the most common APIs are to either inherit stdin/stdout, route to null, or to have a pipe. All seems valuable and doable.
- What other methods should there be? I think kill (exposing perhaps some basic signals) and wait?
- Where do the programs come from? From the file system seems nice, but what if you want to bundle binaries in your component? I think just files is the way to go, to mirror OS exec.
The alternative to exec I can imagine is a high-level instantiate API that can run arbitrary components (be it wasi:cli commands, or some HTTP handler, or anything). You could implement exec on top of that, but it would be hairy, especially for interposing files/sockets/etc. Because of that complexity I think both wasi:exec and instantiate could very reasonably coexist.
- Dominant language
- Rust
- Stars
- 5.8k
- Forks
- 333
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from WebAssembly/WASI
-
[http] Request and Response's `new` method is reserved in many languages, inconsistent with sockets. Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
WebAssembly/WASI#961 ·
-
P-http
Difficulty 1/5 Under an hour Newbie friendliness 90/100
WebAssembly/WASI#937 ·
-
Difficulty 1/5 1-3 hours Newbie friendliness 72/100
WebAssembly/WASI#909 ·
-
P-clocks S-inactive
Difficulty 1/5 Under an hour Newbie friendliness 68/100
WebAssembly/WASI#687 ·
-
P-random S-inactive
Difficulty 1/5 Under an hour Newbie friendliness 75/100
WebAssembly/WASI#701 ·
All issues in WebAssembly/WASI
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100