I in no way want to sound like I'm asking for more work to be done for the WasmTime CLI. The speed at which this whole ecosystem is evolving is great. I just wanted to ask if the idea of using the WasmTime CLI to sandbox a wasm image pulled from a service somewhere that only needed read-access to directories and files within it had ever come up?
I know I could write my own embedder to do that, but it would never have the same level of trust that a tool coming from the Bytecode Alliance
would have - when the tool's documentation states that a certain command-line argument would grant the WASM image only read access to the directory's contents. The service could provide the shell script that called the WasmTime CLI and the user could rest assured the directory they passed to the script could be read but not modified.
Maybe someone knows of a fork that is already working towards that level of trust?
Wasmtime's WASI support actually has support for readonly directories but it's not exposed through the command line right now. For example this line assumes all permissions. I think extending the CLI syntax to support a readonly flag might make sense there if you're interested in sending a PR?
So the first DirPerms
argument could say the directory is provided by the host as read-only and the second, FilePerms
, could say the files themselves are also read-only? That's nice. I was under the impression only creating new files could be disallowed. There is definitely some bike-shedding warranted on the CLI argument. Is this the right place? Instead of --dir
, it could be --dir-readonly
. But naming things is hard and I would be happy with any name as its really the fact that the final binary is coming from you and the documentation spells out the promise it is making that's important.
I'm certainly up for sending a PR! If you prefer, the better names discussion could be part of the PR.
Ah bikeshedding can happen wherever, but probably best to do in a PR yeah. As for inspiration I know docker
has modes like this but I also know their CLI syntax for volumes has evolved over time. Otherwise though I'm not sure what the best syntax is here myself, so seems reasonable to take a stab at something and we can see how it works out
Last updated: Dec 23 2024 at 12:05 UTC