Direct disk/filesystem access

[Simonl9l]

per the GA announcement https://extism.org/blog/announcing-extism/#how-we-built-it

"It's important to keep safety and security in mind, and as such, we've decided to hold off on enabling direct disk/filesystem access from plug-ins , and instead opt for a more explicit requirement to pass file data in and out of a plug-in directly. We're experimenting with approaches here and would appreciate your feedback."

Do you have anything to share yet on the experimenting?

Our solution uses plugins to allows customer to develop adapters that will allow them to get data (from files or other API's etc.) in and out of our system. For input adapters they can access their file and use host functions to pass in the specific value for each its they want to pass in.

When would we be able to access these experimental approaches? Thanks!

[mhmd-azeez]

@Simonl9l you can give the plugins access to the file system, you just have to specify it in the manifest explicitly.

Docs: https://extism.github.io/dotnet-sdk/api/Extism.Sdk.Manifest.html#Extism_Sdk_Manifest_AllowedPaths

Example: https://github.com/extism/dotnet-sdk/blob/main/test/Extism.Sdk/BasicTests.cs#L87

[Simonl9l]

thanks for the link to the docs, for some reason they are not obviously visible from elsewhere!

[Simonl9l]

Ah - please can you help interpret the difference betwen source and destination for Allowed Paths - https://extism.github.io/dotnet-sdk/api/Extism.Sdk.Manifest.html#Extism_Sdk_Manifest_AllowedPaths

if relative is that relative to the manifest file, or the host process?

[mhmd-azeez]

@Simonl9l source is the path on the host side. For example, lets say you want to create a folder for each plugin like so:
D:/plugins/123/ and then destination is the path that will be available for the plugin. For example /mnt (WASI has a UNIX-style file system)

So the plugin thinks all of the files in D:/plugins/123 are in the /mnt folder. Basically you're creating a virtual file system for the plugin. This is the folder the test reads from: https://github.com/extism/dotnet-sdk/tree/main/test/Extism.Sdk/data

if relative is that relative to the manifest file, or the host process?

The source path is relative to the host process (but you can provide an absolute path too)

[henriklundgren]

I am struggling to get allowed_paths to work but without success.

If I inline the path in the host_fn it works as expected.

I am using Rust (v1.78) both as host language and plugin language.

I tried both absolute path and relative (still unclear what it is relative to).

Any help appreciated, thanks.

hostfn!(read(path: String) {
	fs::read_dir(path);
});

Manifest {
	wasm: vec![url],
	allowed_paths: Some(BTreeMap::from([
		(
			// PathBufs
			"/home/NAME/Target",
			"/Target"
		)
	])),
}

// ---- Plugin ----

#[host_fn]
extern "ExtismHost" {
	fn read(path: String);
}

#[plugin_fn]
fn get(path: String) {
	unsafe { read(path) }
}

Edit: added code

[nilslice]

@henriklundgren - since you’re using your own host function read, the Manifest configuration does not apply. In the way you have it, your host function goes around the protections / limitations defined in the Manifest - which is fine, just be sure you are ok with a plugin having access to any path on the host.

Using the Manifest, you can map the paths like you have, but compile using —-target wasm32-wasi, and then you can use normal std library code to read from the /Target path which through WASI would map to the hosts /home/NAME/Target path.

[henriklundgren]

@nilslice Thanks, works now!

[nilslice]

@henriklundgren, glad to hear it! we could improve the docs on this, sorry for the confusion.