Stream: wasmtime

Topic: Defining custom component model, provide Windows Reg access


view this post on Zulip 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

view this post on Zulip 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.

view this post on Zulip 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?

view this post on Zulip 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.

view this post on Zulip Lann Martin (Jan 16 2024 at 14:45):

Yep that sounds right to me.


Last updated: Dec 23 2024 at 13:07 UTC