Wasmtime GitHub notifications bot (Mar 09 2023 at 17:49): Wasmtime GitHub notifications bot (Mar 09 2023 at 17:49):danxexe opened issue #5974:
Are there any plans to support this on the CLI for preopened directories? https://github.com/WebAssembly/wasi-filesystem/pull/91
My use case is adding a "scripting" layer to an application where I need to make some files available to untrusted wasm modules. The modules should not be able to modify these files. Ideally this should be done without relying on the underlying OS permissions. Is there any way to do this on the current version?
Wasmtime GitHub notifications bot (Mar 09 2023 at 18:00):jameysharp commented on issue #5974:
I'm guessing that @sunfishcode intends for Wasmtime to expose this flag, but since support for WASI preview 2 is still under heavy development it may be a bit before this lands.
@sunfishcode, is that right? How hard would this be for an interested party to contribute support for?
Wasmtime GitHub notifications bot (Mar 09 2023 at 18:04):pchickey commented on issue #5974:
If you are embedding wasmtime (as a crate), you can achieve this by writing a pair of
WasiDir/WasiFileimpls that wraps an existingdyn WasiDir/dyn WasiFilein one that rejects all write operations, otherwise passes operations through, and propagates that property to opened dirs/files.
Wasmtime GitHub notifications bot (Mar 09 2023 at 18:29):danxexe commented on issue #5974:
If you are embedding wasmtime (as a crate), you can achieve this by writing a pair of
WasiDir/WasiFileimpls that wraps an existingdyn WasiDir/dyn WasiFilein one that rejects all write operations, otherwise passes operations through, and propagates that property to opened dirs/files.It's not a Rust app, I'm currently shelling out to the wasmtime CLI. I wanted to do this without writing a custom wrapper, but I will take a look into this suggestion, thanks.
Wasmtime GitHub notifications bot (Feb 25 2024 at 03:52):SnoopJ commented on issue #5974:
Not sure from reading this thread if this feature is intended at some point, but I've just run into a use-case with the
wasmtime-pybindings where this requested functionality would have been very convenient. Would be nice to know if it's something possibly on the horizon for the runtime.
Wasmtime GitHub notifications bot (Feb 26 2024 at 16:57):pchickey commented on issue #5974:
Read-only permissions can now be specified directly in the wasmtime-wasi::preview2::WasiCtxBuilder::preopened_dir method. This isn't yet the implementation used by the c-api that drives wasmtime-py, but we will be switching the c-api to that implementation soon, at which point we could add a new c-api function to expose providing a preopen with permissions, and then finally it could be exposed in wasmtime-py.
We don't currently have anyone actively maintaining wasmtime-py, though, so that step will need someone interested to step up.
Wasmtime GitHub notifications bot (Feb 26 2024 at 18:51):SnoopJ commented on issue #5974:
Interesting, I had missed that this was capable from the Rust side. If I understand the bindings generation machinery for
wasmtime-py, whatever is in the C API should be picked up pretty much automatically, although the Python-facing code may need special care.If there is an open issue that you could refer me to for exposing that machinery in the C API, I'd be happy to keep an eye on it and perhaps make an attempt (no promises!) at updating the bindings when the time is right.
In the meantime, I may see how much fuss it would be to set up the runtime from ad-hoc Rust code. I have relatively simple needs for control over the configuration/etc. from the Python consumer side, so it might not be so bad to do it that way.
Thanks!
Wasmtime GitHub notifications bot (Mar 25 2024 at 19:01):FrankReh commented on issue #5974:
wasmtime-wasi::preview2::WasiCtxBuilder::preopened_dir
The link is now https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.preopened_dir
Last updated: Dec 23 2024 at 12:05 UTC