[simonw]

Wow that's almost what I want.

    wget https://github.com/brettcannon/cpython-wasi-build/releases/download/v3.13.0/python-3.13.0-wasi_sdk-24.zip
    unzip python-3.13.0-wasi_sdk-24.zip
    wasmtime run --dir .::/ python.wasm -c 'print("hello world")'

So far so good! But... it looks like that --dir option mounts the current directory as both readable and writable:

    wasmtime run --dir .::/ python.wasm -c 'print(len(open("python.wasm", "rb").read()))'
    # Outputs 28775526

But malicious code can break the system like this:

    wasmtime run --dir .::/ python.wasm -c 'open("python.wasm", "wb").write(b"blah")'

And now it fails with an error if you try to run it because we over-wrote python.wasm. Even if I move python.wasm out of the current directory I'd still be able to break things by breaking those other lib files.

Although... I guess I could use unix filesystem permissions to make those read-only? That could work.

[conroy]

This is just a limitation of the wasmtime CLI. The full Rust API let's you mount filesystems as read-only. Not sure why it's not exposed as an argument.

[simonw]

Thanks - I just found an open issue for exposing that in the Python API: https://github.com/bytecodealliance/wasmtime-py/issues/251

[compressedgas]

You might need to wrap the wasmtime command in firejail or bubblewrap with appropriate arguments to get the operation restrictions you want.

[sitkack]

While that might be a workable stop gap, there is zero reason why this couldn’t be handle in the wasi shim layer. This is exactly what wasi was designed for.