wasi:exec

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.

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.