Stream: git-wasmtime

Topic: wasmtime / issue #5289 How to enable full filesystem acce...

Wasmtime GitHub notifications bot (Nov 17 2022 at 13:55):

Berrysoft opened issue #5289:

As far as I know, we can use preopened_dir to preopen some directories and give WASM binary a limited filesystem access. However, I can't find a simple way to give the binary a full filesystem access. The following code doesn't work (with wasi-cap-std-sync) on Windows:

WasiCtxBuilder::new().ipreopened_dir(cap_std::fs::Dir::from_std_file(std::fs::File::open("/")?), "/")?.build()

I would also like a cross-platform way to give full filesystem access.

Wasmtime GitHub notifications bot (Nov 17 2022 at 13:55):

Berrysoft edited issue #5289:

As far as I know, we can use preopened_dir to preopen some directories and give WASM binary a limited filesystem access. However, I can't find a simple way to give the binary a full filesystem access. The following code doesn't work (with wasi-cap-std-sync) on Windows:

WasiCtxBuilder::new().preopened_dir(cap_std::fs::Dir::from_std_file(std::fs::File::open("/")?), "/")?.build()

I would also like a cross-platform way to give full filesystem access.

Wasmtime GitHub notifications bot (Nov 17 2022 at 13:59):

sunfishcode commented on issue #5289:

Could you say more about your use case? What would you like to do that requires using both Wasm and full filesystem access?

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:06):

Berrysoft commented on issue #5289:

I'm writing a software that includes a plugin framework. The plugins are WASM. Some of the plugins need to access files from the user input, and I cannot know about the input before creating the WASM runtime. The design of the software also tries to decouple the host and the plugins, so the host even don't know what the plugins will do. Therefore I need to give full filesystem access to the WASMs. If there are some files the host cannot access, it's OK. I only want to enable the same accessbility as the host runtime.

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:07):

Berrysoft edited a comment on issue #5289:

I'm writing a software that includes a plugin framework. The plugins are WASM. Some of the plugins need to access files from the user input, and I cannot know about the input before creating the WASM runtime. The design of the software also tries to decouple the host and the plugins, so the host even don't know what the plugins will do. Therefore I need to give full filesystem access to the WASMs. If there are some files the host cannot access, it's OK. I only want to enable the same accessibility as the host runtime.

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:13):

bjorn3 commented on issue #5289:

Some of the plugins need to access files from the user input, and I cannot know about the input before creating the WASM runtime.

Assuming your software has a gui, selecting files likely uses a file dialog presented by the host. You could make the host use wasi_ctx.table().push(Box::new(FileEntry::new(caps, file))) after the user picked a file and then pass the returned fd to the guest I think.

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:18):

Berrysoft commented on issue #5289:

@bjorn3 What about this case: the user input is a JSON with some paths, and the JSON plugin parses the JSON and go to find the files. The host cannot know about the paths except parsing the JSON itself. However the user input may be TOML or XML or YAML besides JSON. The format is defined by plugins but not host. Therefore the host cannot preopen the directory this time.

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:30):

bjorn3 commented on issue #5289:

I see. In that case try something like

let mut builder = WasiCtxBuilder::new();
for drive in some_function_that_lists_all_drives() {
    builder.preopened_dir(cap_std::fs::Dir::from_std_file(std::fs::File::open(format!("{drive}:"))?), format!("/{drive}"))?;
}
let ctx = builder.build();

Then you can access C:\foo\bar.txt as /c/foo/bar.txt inside the guest.

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:43):

Berrysoft commented on issue #5289:

A passable solution anyway, but I would appreciate a much prettier one. This solution needs platform-specific code, and the user input path should be change from C:\foo\bar.txt to /c/foo/bar.txt, which may make the following code much more complicated.

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:43):

sunfishcode commented on issue #5289:

@Berrysoft It's a little unclear from your message; is that your actual use case, or is it a hypothetical use case?

Wasmtime GitHub notifications bot (Nov 17 2022 at 14:50):

Berrysoft commented on issue #5289:

@sunfishcode It is nearly the same as my actual use case. In the actual case, the difference between user input is not the format, but the custom (YAML) properties. Only the plugins know the specific property name, and go to find the files. However not all the custom properties are paths, and even the paths are relative ones to other properties, therefore the host runtime cannot try to parse all the values and try to preopen the files.

Wasmtime GitHub notifications bot (Nov 22 2022 at 22:05):

sunfishcode commented on issue #5289:

@Berrysoft Do users know that all the paths will have a common parent directory that isn't a root directory? If so, they could add pre-opens for the parent directory (or directories).

If not, that is indeed something the sandboxing model doesn't handle well. In order to make Wasm components composable with other Wasm components, we're trying to avoid depending on filesystem namespaces being implicitly shared between programs. That's difficult to do if a component expects to read from something on the outside which assumes it's in the same filesystem namespace and can resolve path names.

Last updated: Dec 23 2024 at 12:05 UTC