Path normalization causes more accepted file paths

[yagehu]

Describe the bug Due to the path.Clean() call in the atPath() implementation, some paths that are rejected by other runtimes are OK in Wazero. For example, given a preopen directory fd and the path a/../a, path.Clean() would normalize away the .. and produce a as the final path. In runtimes such as Wasmtime and WAMR, since the first a/ does not exist, a call involving that path returns noent (44).

To Reproduce This snippet will fail with Wasmtime, WAMR, WasmEdge, Wasmer. But Wazero creates the link a pointing to link successfully.

fn main() {
    unsafe {
        let base_fd = 3;

        wasi::path_symlink("link", base_fd, "a/../a").unwrap();
    }
}

Environment (please complete the relevant information):

• Go version: 1.22.3
• wazero Version: bf42c25657484ba65ec2a4c39adfba43b2666680
• Host architecture: amd64
• Runtime mode: compiler

Additional context The only other runtime that has the same behavior is Node with uvwasi. That's because uvwasi uses libuv which doesn't have an openat(2) equivalent (yet!).

The wasi-filesystem spec describes a path resolution implementation that conflicts with the usage of path.Clean and similar path normalization strategies.

[evacchi]

well, personally I am not against converging with other implementations, I suppose this used to be underspecified

[yagehu]

well, personally I am not against converging with other implementations, I suppose this used to be underspecified

I can take a stab at it.