wasmtime / issue #6978 Using wasmtime_wasi `Dir` struct c... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #6978 Using wasmtime_wasi `Dir` struct c...

Wasmtime GitHub notifications bot (Sep 08 2023 at 01:51):

doinkythederp opened issue #6978:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

Here's the WASM code required to reproduce this bug:

fn main() {
    let dir = std::fs::read_dir("/").unwrap();
    println!("{:?}", dir.collect::<Vec<_>>());
}

cargo build --target wasm32-wasi --release

Compiled in release mode with debug = true:
test.wasm.tgz

Here's the Rust host code required, modified from the WASI example:

use wasmtime::*;
use wasmtime_wasi::{ambient_authority, sync::WasiCtxBuilder, Dir};

fn main() -> Result<()> {
    // Define the WASI functions globally on the `Config`.
    let engine = Engine::default();
    let mut linker = Linker::new(&engine);
    wasmtime_wasi::add_to_linker(&mut linker, |s| s)?;

    let wasm_fs = Dir::open_ambient_dir("/", ambient_authority())
        .expect("Filesystem root should be accessible");

    // Create a WASI context and put it in a Store; all instances in the store
    // share this context. `WasiCtxBuilder` provides a number of ways to
    // configure what the target program will have access to.
    let wasi = WasiCtxBuilder::new()
        .preopened_dir(wasm_fs, "/")
        .unwrap()
        .inherit_stdio()
        .inherit_args()?
        .build();
    let mut store = Store::new(&engine, wasi);

    // Instantiate our module with the imports we've created, and run it.
    let module = Module::from_file(&engine, "./test.wasm")?;
    linker.module(&mut store, "", &module)?;
    // --> Panic occurs here
    linker
        .get_default(&mut store, "")?
        .typed::<(), ()>(&store)?
        .call(&mut store, ())?;

    Ok(())
}

Steps to Reproduce

Use wasmtime_wasi::Dir to allow access to the root directory
Attempt to read the root directory from WASM

Expected Results

The program will print the files in the root directory: bin, dev, usr, etc.

Actual Results

Program panics:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromIntError(())', <...>/cap-primitives-2.0.0/src/rustix/fs/metadata_ext.rs:167:49

Versions and Environment

Wasmtime version or commit: v12.0.1

Operating system: macOS Ventura 13.5.1

Architecture: arm64 Apple Silicon

Extra Info

I'm not familiar with ambient authority.

Wasmtime GitHub notifications bot (Sep 08 2023 at 01:51):

doinkythederp added the bug label to Issue #6978.

Wasmtime GitHub notifications bot (Sep 08 2023 at 01:51):

doinkythederp edited issue #6978:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

Here's the WASM code required to reproduce this bug:

fn main() {
    let dir = std::fs::read_dir("/").unwrap();
    println!("{:?}", dir.collect::<Vec<_>>());
}

cargo build --target wasm32-wasi --release

Compiled in release mode with debug = true:
test.wasm.tgz

Here's the Rust host code required, modified from the WASI example:

use wasmtime::*;
use wasmtime_wasi::{ambient_authority, sync::WasiCtxBuilder, Dir};

fn main() -> Result<()> {
    // Define the WASI functions globally on the `Config`.
    let engine = Engine::default();
    let mut linker = Linker::new(&engine);
    wasmtime_wasi::add_to_linker(&mut linker, |s| s)?;

    let wasm_fs = Dir::open_ambient_dir("/", ambient_authority())
        .expect("Filesystem root should be accessible");

    // Create a WASI context and put it in a Store; all instances in the store
    // share this context. `WasiCtxBuilder` provides a number of ways to
    // configure what the target program will have access to.
    let wasi = WasiCtxBuilder::new()
        .preopened_dir(wasm_fs, "/")
        .unwrap()
        .inherit_stdio()
        .inherit_args()?
        .build();
    let mut store = Store::new(&engine, wasi);

    // Instantiate our module with the imports we've created, and run it.
    let module = Module::from_file(&engine, "./test.wasm")?;
    linker.module(&mut store, "", &module)?;
    // --> Panic occurs here
    linker
        .get_default(&mut store, "")?
        .typed::<(), ()>(&store)?
        .call(&mut store, ())?;

    Ok(())
}

Steps to Reproduce

Use wasmtime_wasi::Dir to allow access to the root directory
Attempt to read the root directory from WASM

Expected Results

The program will print the files in the root directory: bin, dev, usr, etc.

Actual Results

Program panics:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromIntError(())', <...>/cap-primitives-2.0.0/src/rustix/fs/metadata_ext.rs:167:49

Versions and Environment

Wasmtime version or commit: v12.0.1

Operating system: macOS Ventura 13.5.1

Architecture: arm64 Apple Silicon

Extra Info

I'm not familiar with ambient authority.

```[tasklist]

Tasks

~~~

Wasmtime GitHub notifications bot (Sep 08 2023 at 01:51):

doinkythederp edited issue #6978:

Thanks for filing a bug report! Please fill out the TODOs below.

Note: if you want to report a security issue, please read our security policy!

Test Case

Here's the WASM code required to reproduce this bug:

fn main() {
    let dir = std::fs::read_dir("/").unwrap();
    println!("{:?}", dir.collect::<Vec<_>>());
}

cargo build --target wasm32-wasi --release

Compiled in release mode with debug = true:
test.wasm.tgz

Here's the Rust host code required, modified from the WASI example:

use wasmtime::*;
use wasmtime_wasi::{ambient_authority, sync::WasiCtxBuilder, Dir};

fn main() -> Result<()> {
    // Define the WASI functions globally on the `Config`.
    let engine = Engine::default();
    let mut linker = Linker::new(&engine);
    wasmtime_wasi::add_to_linker(&mut linker, |s| s)?;

    let wasm_fs = Dir::open_ambient_dir("/", ambient_authority())
        .expect("Filesystem root should be accessible");

    // Create a WASI context and put it in a Store; all instances in the store
    // share this context. `WasiCtxBuilder` provides a number of ways to
    // configure what the target program will have access to.
    let wasi = WasiCtxBuilder::new()
        .preopened_dir(wasm_fs, "/")
        .unwrap()
        .inherit_stdio()
        .inherit_args()?
        .build();
    let mut store = Store::new(&engine, wasi);

    // Instantiate our module with the imports we've created, and run it.
    let module = Module::from_file(&engine, "./test.wasm")?;
    linker.module(&mut store, "", &module)?;
    // --> Panic occurs here
    linker
        .get_default(&mut store, "")?
        .typed::<(), ()>(&store)?
        .call(&mut store, ())?;

    Ok(())
}

Steps to Reproduce

Use wasmtime_wasi::Dir to allow access to the root directory
Attempt to read the root directory from WASM

Expected Results

The program will print the files in the root directory: bin, dev, usr, etc.

Actual Results

Program panics:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromIntError(())', <...>/cap-primitives-2.0.0/src/rustix/fs/metadata_ext.rs:167:49

Versions and Environment

Wasmtime version or commit: v12.0.1

Operating system: macOS Ventura 13.5.1

Architecture: arm64 Apple Silicon

Extra Info

I'm not familiar with ambient authority.

Wasmtime GitHub notifications bot (Sep 08 2023 at 21:38):

pchickey commented on issue #6978:

it looks like this is a cap-primitives crate bug, can you please report it here: https://github.com/bytecodealliance/cap-std/issues

Wasmtime GitHub notifications bot (Sep 08 2023 at 22:37):

doinkythederp commented on issue #6978:

I'm not familiar with how wasmtime_wasi uses the Dir struct and I don't know anything about cap-primitives so I'm not really sure what to put in the bug report

Wasmtime GitHub notifications bot (Sep 09 2023 at 09:16):

bjorn3 commented on issue #6978:

It looks like u64::try_from(stat.st_dev).unwrap() fails. On Linux dev_t is a u64, but on macOS it is an i32: https://github.com/rust-lang/libc/blob/835661543db1ec42a6d9a809d69c3c5b5b978b81/src/unix/bsd/apple/mod.rs#L9 Presumably it is a negative number in this case. Could you try stat /* and see which dir gets which device number?

Wasmtime GitHub notifications bot (Sep 10 2023 at 03:20):

pchickey assigned issue #6978 to sunfishcode.

Wasmtime GitHub notifications bot (Sep 13 2023 at 01:25):

doinkythederp commented on issue #6978:

Not sure what to make of this:

$ stat /*
16777234 87498924 drwxrwxr-x 86 root admin 0 2752 "Sep 12 18:14:56 2023" "Sep 12 18:14:56 2023" "Sep 12 18:14:56 2023" "Sep  2 00:35:13 2023" 4096 0 0x100000 /Applications
16777234 87484854 drwxr-xr-x 72 root wheel 0 2304 "Sep  7 20:23:48 2023" "Sep  7 20:23:26 2023" "Sep  7 20:23:26 2023" "Sep  2 00:35:13 2023" 4096 0 0x100000 /Library
16777234 1152921500311879701 drwxr-xr-x 10 root wheel 0 320 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x80000 /System
16777234 23836 drwxr-xr-x 6 root admin 0 192 "Sep  7 20:23:21 2023" "Sep  7 20:22:54 2023" "Sep  7 20:22:54 2023" "Aug 24 01:59:39 2022" 4096 0 0x100000 /Users
16777234 26293 drwxr-xr-x 3 root wheel 0 96 "Sep 11 19:52:22 2023" "Sep 11 19:52:22 2023" "Sep 11 19:52:22 2023" "Aug 24 01:59:39 2022" 4096 0 0x8000 /Volumes
16777234 1152921500312435255 drwxr-xr-x 39 root wheel 0 1248 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /bin
16777234 26295 drwxr-xr-x 2 root wheel 0 64 "Sep 22 17:50:54 2022" "Aug 24 01:59:39 2022" "Sep 22 17:50:54 2022" "Aug 24 01:59:39 2022" 4096 0 0x8000 /cores
855137406 335 dr-xr-xr-x 4 root wheel 0 5023 "Sep 12 18:24:40 2023" "Sep  7 20:22:04 2023" "Sep  7 20:22:04 2023" "Dec 31 16:00:00 1969" 512 10 0x8000 /dev
16777234 1152921500312435332 lrwxr-xr-x 1 root wheel 0 11 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /etc
16777234 1152921504606781440 lrwxr-xr-x 1 root wheel 0 25 "Sep  7 20:23:38 2023" "Sep  7 20:23:38 2023" "Sep  7 20:23:38 2023" "Sep  7 20:23:38 2023" 4096 0 0x8000 /home
16777240 2 drwxr-xr-x 5 root nixbld 0 160 "Sep  8 14:52:37 2023" "Sep  8 14:52:31 2023" "Sep  8 14:52:31 2023" "Sep  8 14:52:12 2023" 4096 0 0 /nix
16777234 26292 drwxr-xr-x 4 root wheel 0 128 "Mar  9 17:51:16 2023" "Mar  3 22:04:09 2023" "Mar  3 22:04:09 2023" "Aug 24 01:59:39 2022" 4096 0 0x8000 /opt
16777234 87497982 drwxr-xr-x 6 root wheel 0 192 "Sep  8 08:24:55 2023" "Sep  7 20:23:34 2023" "Sep  7 20:23:34 2023" "Sep  2 00:35:13 2023" 4096 0 0x108000 /private
16777234 1152921504606781443 lrwxr-xr-x 1 root wheel 0 15 "Sep  8 15:03:25 2023" "Sep  8 15:03:25 2023" "Sep  8 15:03:25 2023" "Sep  8 15:03:25 2023" 4096 0 0 /run
16777234 1152921500312435335 drwxr-xr-x 64 root wheel 0 2048 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /sbin
16777234 1152921500312435438 lrwxr-xr-x 1 root wheel 0 11 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /tmp
16777234 1152921500312435439 drwxr-xr-x 11 root wheel 0 352 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /usr
16777234 1152921500312470639 lrwxr-xr-x 1 root wheel 0 11 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /var

Wasmtime GitHub notifications bot (Sep 13 2023 at 01:27):

doinkythederp edited a comment on issue #6978:

Not sure what to make of this:

$ stat /*
16777234 87498924 drwxrwxr-x 86 root admin 0 2752 "Sep 12 18:14:56 2023" "Sep 12 18:14:56 2023" "Sep 12 18:14:56 2023" "Sep  2 00:35:13 2023" 4096 0 0x100000 /Applications
16777234 87484854 drwxr-xr-x 72 root wheel 0 2304 "Sep  7 20:23:48 2023" "Sep  7 20:23:26 2023" "Sep  7 20:23:26 2023" "Sep  2 00:35:13 2023" 4096 0 0x100000 /Library
16777234 1152921500311879701 drwxr-xr-x 10 root wheel 0 320 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x80000 /System
16777234 23836 drwxr-xr-x 6 root admin 0 192 "Sep  7 20:23:21 2023" "Sep  7 20:22:54 2023" "Sep  7 20:22:54 2023" "Aug 24 01:59:39 2022" 4096 0 0x100000 /Users
16777234 26293 drwxr-xr-x 3 root wheel 0 96 "Sep 11 19:52:22 2023" "Sep 11 19:52:22 2023" "Sep 11 19:52:22 2023" "Aug 24 01:59:39 2022" 4096 0 0x8000 /Volumes
16777234 1152921500312435255 drwxr-xr-x 39 root wheel 0 1248 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /bin
16777234 26295 drwxr-xr-x 2 root wheel 0 64 "Sep 22 17:50:54 2022" "Aug 24 01:59:39 2022" "Sep 22 17:50:54 2022" "Aug 24 01:59:39 2022" 4096 0 0x8000 /cores
855137406 335 dr-xr-xr-x 4 root wheel 0 5023 "Sep 12 18:24:40 2023" "Sep  7 20:22:04 2023" "Sep  7 20:22:04 2023" "Dec 31 16:00:00 1969" 512 10 0x8000 /dev
16777234 1152921500312435332 lrwxr-xr-x 1 root wheel 0 11 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /etc
16777234 1152921504606781440 lrwxr-xr-x 1 root wheel 0 25 "Sep  7 20:23:38 2023" "Sep  7 20:23:38 2023" "Sep  7 20:23:38 2023" "Sep  7 20:23:38 2023" 4096 0 0x8000 /home
16777240 2 drwxr-xr-x 5 root nixbld 0 160 "Sep  8 14:52:37 2023" "Sep  8 14:52:31 2023" "Sep  8 14:52:31 2023" "Sep  8 14:52:12 2023" 4096 0 0 /nix
16777234 26292 drwxr-xr-x 4 root wheel 0 128 "Mar  9 17:51:16 2023" "Mar  3 22:04:09 2023" "Mar  3 22:04:09 2023" "Aug 24 01:59:39 2022" 4096 0 0x8000 /opt
16777234 87497982 drwxr-xr-x 6 root wheel 0 192 "Sep  8 08:24:55 2023" "Sep  7 20:23:34 2023" "Sep  7 20:23:34 2023" "Sep  2 00:35:13 2023" 4096 0 0x108000 /private
16777234 1152921504606781443 lrwxr-xr-x 1 root wheel 0 15 "Sep  8 15:03:25 2023" "Sep  8 15:03:25 2023" "Sep  8 15:03:25 2023" "Sep  8 15:03:25 2023" 4096 0 0 /run
16777234 1152921500312435335 drwxr-xr-x 64 root wheel 0 2048 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /sbin
16777234 1152921500312435438 lrwxr-xr-x 1 root wheel 0 11 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /tmp
16777234 1152921500312435439 drwxr-xr-x 11 root wheel 0 352 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /usr
16777234 1152921500312470639 lrwxr-xr-x 1 root wheel 0 11 "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" "Sep  2 00:35:13 2023" 4096 0 0x88000 /var

"The default format displays the st_dev, st_ino, st_mode, st_nlink, st_uid, st_gid, st_rdev, st_size, st_atime, st_mtime, st_ctime, st_birthtime, st_blksize, st_blocks, and st_flags fields, in that order."

Wasmtime GitHub notifications bot (Sep 13 2023 at 10:37):

bjorn3 commented on issue #6978:

All these dev numbers are positive. Could you also try stat /? Maybe it is the root directory itself for which the dev number is negative?

Wasmtime GitHub notifications bot (Sep 13 2023 at 17:38):

alexcrichton commented on issue #6978:

Thanks for helping to track this down @bjorn3, I've posted a hypothetical fix at https://github.com/bytecodealliance/cap-std/pull/329, although I don't understand enough here to know if st_dev being negative is a bad thing or not. Once that's released I can help update it here in Wasmtime to get tested by @doinkythederp

Wasmtime GitHub notifications bot (Sep 13 2023 at 19:05):

doinkythederp commented on issue #6978:

Hi again! Looks like the number changed after a restart or something and the error isn't happening anymore. I haven't changed anything in my code. This might make it harder for me to help with debugging.

Last updated: Dec 23 2024 at 12:05 UTC