Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runners and wasmer_wasix::wapm don't take the [fs] table into account #3744

Closed
Michael-F-Bryan opened this issue Apr 5, 2023 · 2 comments · Fixed by #3913
Closed

Runners and wasmer_wasix::wapm don't take the [fs] table into account #3744

Michael-F-Bryan opened this issue Apr 5, 2023 · 2 comments · Fixed by #3913
Assignees
Labels
📦 lib-wasi About wasmer-wasi priority-medium Medium priority issue 📦 wapm About WAPM
Milestone

Comments

@Michael-F-Bryan
Copy link
Contributor

Michael-F-Bryan commented Apr 5, 2023

Describe the bug

The current runner implementation (used by wasmer run and wasmer run-unstable) don't respect the directory mappings in the wasmer.toml file's [fs] table.

Steps to reproduce

The easiest way to reproduce this is by creating a package that will serve static files, where the original location on the publishing machine's filesystem doesn't match the directory the WASI executable will see.

# wasmer.toml

[package]
name = "Michael-F-Bryan/wasmer-io"
version = "0.2.0"
description = "The wasmer.io website"

[dependencies]
"sharrattj/static-web-server" = "1"

[fs]
public = "out"

Expected Solution

There are two ways we could resolve this.

The first one is by making sure consumers of a *.webc file respect the [fs] mapping. At the moment our runners use the naive WebcFileSystem::init_all() method to set up the volumes (here), and that just implements a poor man's unionfs with all the volumes.

Alternatively, the wapm-targz-to-pirita could shuffle directories around as part of the general tarball-to-webc conversion.

@Michael-F-Bryan Michael-F-Bryan self-assigned this Apr 11, 2023
@Michael-F-Bryan Michael-F-Bryan added 📦 lib-wasi About wasmer-wasi 📦 wapm About WAPM priority-medium Medium priority issue labels Apr 11, 2023
@Michael-F-Bryan
Copy link
Contributor Author

We should also check that people can't do something nefarious like [fs] public = "/etc/shadow".

@Michael-F-Bryan Michael-F-Bryan added this to the v3.3 milestone Apr 11, 2023
@Michael-F-Bryan Michael-F-Bryan modified the milestones: v3.3, v4.0 May 2, 2023
@Michael-F-Bryan
Copy link
Contributor Author

I haven't implemented it in #3852, but I've left some placeholders for the solution.

This is where the resolver should figure out how volumes should be mapped:

fn resolve_filesystem_mapping(
_dependency_graph: &DependencyGraph,
) -> Result<Vec<FileSystemMapping>, ResolveError> {
// TODO: Add filesystem mappings to summary and figure out the final mapping
// for this dependency graph.
// See <https://github.com/wasmerio/wasmer/issues/3744> for more.
Ok(Vec::new())
}

And this is where we take WEBC containers and do the actual mapping:

fn filesystem(
packages: &HashMap<PackageId, Container>,
pkg: &ResolvedPackage,
) -> Result<impl FileSystem + Send + Sync, Error> {
// FIXME: Take the [fs] table into account
// See <https://github.com/wasmerio/wasmer/issues/3744> for more
let root = &packages[&pkg.root_package];
let fs = WebcVolumeFileSystem::mount_all(root);
Ok(fs)
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📦 lib-wasi About wasmer-wasi priority-medium Medium priority issue 📦 wapm About WAPM
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant