This extends wazero's interpretation of rights in wasi_snapshot_preview1.path_open to allow programs to open files in either read-only, write-only, or read-write mode.
Signed-off-by: Achille Roussel <achille.roussel@gmail.com>
Co-authored-by: Crypt Keeper <64215+codefromthecrypt@users.noreply.github.com>
This adds a new type `internalapi.WazeroOnly` which should be embedded on types users are likely to accidentally implement despite docs saying otherwise.
Signed-off-by: Nuno Cruces <ncruces@users.noreply.github.com>
This adds `gojs.WithOSUser` which passes through current user IDs so
that GOOS=js compiled wasm can read them. This also adds support for
reading back the uid and gid on files. In summary, this passes
`os.TestChown` except on windows where it will not work due to lack of
support.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
In order to support more configuration, we should stop using context as
it is getting gnarly.
Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This changes the experimental flag introduced yesterday to
`-experimental-workdir-inherit=true`, to reduce edge cases needed to
produce the same behavior as go's wasm test runner.
After this, we have the same failure count, though the latter is likely
related to my machine:
```bash
$ wasm=$PWD/os.wasm; (cd $(go env GOROOT)/src/os; wazero run -mount=/:/ --experimental-workdir-inherit=true $wasm)
--- FAIL: TestMkdirAllAtSlash (0.00s)
path_test.go:111: MkdirAll "/_go_os_test/dir": mkdir /_go_os_test: I/O error, I/O error
--- FAIL: TestOpenFileLimit (0.01s)
rlimit_test.go:31: open rlimit.go: I/O error
FAIL
```
See https://github.com/golang/go/blob/master/misc/wasm/wasm_exec_node.js#L24
Signed-off-by: Adrian Cole <adrian@tetrate.io>
Interesting issue due to a lot of weird interactions between
path handling and system defaults.
The test will pass outside of CI (e.g. on my local machine),
because usually you will run this on C:\, which is the root
of your filesystem.
However, GitHub Actions mounts the test filesystem on D:,
causing the path handling routines to miss it.
You can simulate this even if you don't have a second drive:
assuming you have `wazero` under `%USERPROFILE%\Devel\wazero`
subst X: %USERPROFILE%\Devel
cd X:\wazero
make test
However, we are ignoring path information because:
```go
func WithWorkdir(ctx context.Context, workdir string) context.Context {
// Ensure if used on windows, the input path is translated to a POSIX one.
workdir = workdir[len(filepath.VolumeName(workdir)):]
```
strips the Volume
The other weird bit happens in the test itself:
```
--mount=/:/ --experimental-workdir=$bearDir
```
What is happening here is that we are mount the root of our FS
to / (thereby exposing the entire FS to the test) and then
telling the guest to set the CWD to `$bearDir`.
However, on Windows we don't have a unique `/` (well technically
we do; see [UNC Paths][0] but that's another story) but each `/` has a volume attached.
So, on Windows we shouldn't `--mount=/:/` but rather one root volume
(in fact, the other tests work because they do `--mount=$bearDir:/`)
i.e. X:\ or, more generally `VolumeName($bearDir)`
Finally, although `WithWorkdir` is stripping the volume name,
we should probably pass a path without the volume name or at least ensuring
that that CWD makes sense together with the host mount directive; i.e.
when we pass `--mount=x:\:/` we should either pass `--workdir=\wazero\...`
or ensure that the volume name matches `--workdir=x:\wazero\...` and
return an error otherwise.
For now I am only fixing the test.
[0]: https://learn.microsoft.com/en-us/dotnet/standard/io/file-path-formats
Signed-off-by: Edoardo Vacchi <evacchi@users.noreply.github.com>
When compiled to `GOOS=js`, wasm does not maintain the working
directory: it is defined by the host. While not explicitly documented,
`os.TestDirFSRootDir` in Go suggests the working directory must be valid
to pass (literally the directory holding the file).
This adds an experimental CLI flag that gives the initial working
directory. This is experimental because while GOOS=js uses this, current
WASI compilers will not, as they maintain working directory in code
managed by wasi-libc, or as a convention (e.g. in Zig).
It is not yet known if wasi-cli will maintain working directory
externally or not.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
Many tests failed in gojs due to needing to be resolved against the CWD,
which is atypically stored host side. This fixes that and renames the
"exit" scope to "proc" so we can use it for other proc concerns besides
exit.
This reduces known failures on GOOS=js from 23 to 14:
```bash
$ wazero run -mount=/usr/local/go/src/os:/:ro -mount=/tmp:/tmp -mount=/etc:/etc:ro -mount=/usr:/usr:ro -mount=/dev:/dev:ro os.wasm |grep '^--- FAIL'|wc -l
14
```
See #1222
Signed-off-by: Adrian Cole <adrian@tetrate.io>
While playing with interesting examples to show off Wazero CLI,
I found that older binaries that still use the `wasi_unstable`
namespace are rejected.
This is a small refactoring to support running these binaries
as well.
Signed-off-by: Edoardo Vacchi <evacchi@users.noreply.github.com>
Before, our README said gojs `GOOS=js compiled wasm` was experimental.
However, as we head to 1.0 we should be more explicit about that.
When we started gojs, there was no likely future where `GOOS=wasi` would
happen in the standard go compiler. This has changed, so we'll only keep
the gojs package around until wasi is usable for two Go releases. Being
in an experimental package helps others know to watch out for this.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
- ensure the module initialization function is evaluated
regardless if it's WASI or GoJS
- add a `-timeout duration` flag
- ensure flag gets propagated to the rt config builder
(also ensure cache flag gets propagated to the rt config builder)
- print a message to stderr when the deadline is exceeded
- configure GitHub Actions to use `-timeout=10m` flag
instead of GHA's `timeout-minutes: 10`
Signed-off-by: Edoardo Vacchi <evacchi@users.noreply.github.com>
TestRun clears the environment, which means the os specific temporary
directory is also cleared; which then either creates the directory to
the wrong place or it doesn't have any access to create the directory
altogether.
Move the temporary directory creation before clearing the environment
variables.
Signed-off-by: Egon Elbre <egonelbre@gmail.com>
This adds an `env-inherit` boolean flag which adds all variables to the
guest ENV.
For example, the below `env-reader.wasm` guest will see the variable
`STAR` and anything set via the runner (docker, podman, etc.):
```
--snip--
FROM scratch
COPY --from=build /build/wazero/wazero /bin/wazero
ENTRYPOINT ["/bin/wazero", "run", "-env-inherit", "-cachedir=/cache", "-mount=.:/"]
ENV STAR=wazero
COPY --from=wasm / .
CMD ["env-reader.wasm"]
```
Note: This isn't appropriate otherwise as it will also propagate
variables like PATH and TMPDIR which aren't likely valid on the guest,
or in worst case may risk crashing.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This moves our floor version to the same we'll release 1.0 with: 1.18.
This is congruent with our version policy which is current-2.
Fixes#921
Signed-off-by: Adrian Cole <adrian@tetrate.io>
It is important for understanding the recent trends in Docker and
WebAssembly to see what a Dockerfile looks like in wazero. For example,
things that natively support wasm right now can take off the 4.5MB our
binary would cost, as well hide some of the configuration you can see,
such as coercing arguments or ENV. Since wasm isn't quite prime time in
Docker, some will be happy to use wazero instead or until it is ready.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This allows wasi to see mounts as individual preopens instead of
virtualized under a root. (GOOS=js doesn't use pre-opens so it still
sees a virtual root). This allows us to progress wasi-testsuite rust
tests, but acknowledges a current glitch in zig support, which is
tracked separately as #1077
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This allows you to specify the memory scope amongst existing logging scopes, both in API and the CLI.
e.g for the CLI.
```bash
$ wazero run --hostlogging=memory,filesystem --mount=.:/:ro cat.wasm
```
e.g. for Go
```go
loggingCtx := context.WithValue(testCtx, experimental.FunctionListenerFactoryKey{},
logging.NewHostLoggingListenerFactory(&log, logging.LogScopeMemory|logging.LogScopeFilesystem))
```
This is helpful for emscripten and gojs which have memory reset
callbacks. This will be much more interesting once #1075 is implemented.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This allows you to specify the exit scope amongst existing logging scopes, both in API and the CLI.
e.g for the CLI.
```bash
$ wazero run --hostlogging=exit,filesystem --mount=.:/:ro cat.wasm
```
e.g. for Go
```go
loggingCtx := context.WithValue(testCtx, experimental.FunctionListenerFactoryKey{},
logging.NewHostLoggingListenerFactory(&log, logging.LogScopeExit|logging.LogScopeFilesystem))
```
This is helpful to know if the wasm called exit or if it exited
implicitly. This is one of the few host functions that exists in three
places: assemblyscript, gojs and wasi.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This allows the CLI to use `-hostlogging=filesystem,poll` instead of or
in addition to multiple flags.
This also makes the parameter loggers more debugable by using pointer
receivers. When they are copied, the field names end up garbage in the
debugger.
Finally, this fixes a glitch where we used GOOS=js where we thought we
were using WASI (in cmd tests).
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This allows you to specify the poll scope amongst existing logging scopes, both in API and the CLI.
e.g for the CLI.
```bash
$ wazero run --hostlogging=poll --hostlogging=filesystem --mount=.:/:ro cat.wasm
```
e.g. for Go
```go
loggingCtx := context.WithValue(testCtx, experimental.FunctionListenerFactoryKey{},
logging.NewHostLoggingListenerFactory(&log, logging.LogScopePoll|logging.LogScopeFilesystem))
```
This is particularly helpful to understand side-effects of GC. For
example, in `GOOS=js` GC will trigger events and these have been tricky
to troubleshoot in the past.
Signed-off-by: Adrian Cole <adrian@tetrate.io>
This is to avoid a collision with an emerging wasi-crypto. They will
have both wasi-random and wasi-crypto
Signed-off-by: Adrian Cole <adrian@tetrate.io>
David Desmarais-Michaud