mainrs (Jan 16 2024 at 14:33): mainrs (Jan 16 2024 at 14:33):Hello! My current use-case relies on me having to read out certain registry values. Because the paths and values are known before initializing the module, I wanted to take advantage of a sandboxing approach.
When I define a custom resource inside a WIT interface, can I somehow also implement custom capabilities? I want a similar interface to that of the filesystem access in preview2. "Directories" would be key paths, and each key path has a read and modify capability. I am not entirely sure how I can bind my custom capabilities configuration struct to wasmtime. wasmtime_wasi has the WasiCtxBuilder.
Here is the documentation for the preview2 model that I want to base this approach on: https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/preview2/struct.WasiCtxBuilder.html#method.preopened_dir
Lann Martin (Jan 16 2024 at 14:37):One option would be to use the actual wasi filesystem interface and model your registry entries as files with a custom implementation of WasiDir/WasiFile. This would have the advantage of being compatible with languages that have wasi support but not full component model support.
mainrs (Jan 16 2024 at 14:39):I assume this would mean i have to implement some kind of custom filesystem that I can add to WASI before linking. Or how would the integration look like?
mainrs (Jan 16 2024 at 14:43):For my first approach I'd guess the solution would be to use a custom state as showcased here: https://docs.wasmtime.dev/examples-rust-wasi.html
And the state would host the resourcetable, the wasi_ctx, my own context and the wasi preview1 adapter.
Lann Martin (Jan 16 2024 at 14:45):Yep that sounds right to me.
Last updated: Nov 22 2024 at 17:03 UTC