consistient WASI preview1 rights reporting#6784
Merged
alexcrichton merged 2 commits intomainfrom Aug 2, 2023
Merged
Conversation
pchickey
requested review from
a team,
alexcrichton,
jameysharp and
sunfishcode
and removed request for
a team,
alexcrichton and
jameysharp
alexcrichton
approved these changes
Aug 2, 2023
geekbeast
pushed a commit
to geekbeast/wasmtime
that referenced
this pull request
Aug 6, 2023
… feature/preview2 * 'feature/preview2' of github.com:geekbeast/wasmtime: Change preview2 builder methods to use `&mut self` (bytecodealliance#6770) Add a bindgen test that exercises using error types from a different interface (bytecodealliance#6802) Resolve trappable error types with fully qualified package paths (bytecodealliance#6795) Update the dev-dependency for wit-bindgen to 0.9.0 (bytecodealliance#6800) Fix incorrect sample code in documentation (bytecodealliance#6796) (bytecodealliance#6797) Update preview1 to trap on misaligned pointers (bytecodealliance#6776) Fix posix-signals-on-macos on aarch64-apple-darwin (bytecodealliance#6793) consistient WASI preview1 rights reporting (bytecodealliance#6784) Wasmtime: Introduce `{Module,Component}::resources_required` (bytecodealliance#6789)
eduardomourar
pushed a commit
to eduardomourar/wasmtime
that referenced
this pull request
Aug 18, 2023
* wasi-tests path_open_preopen: hard-code minimum set of required rights * preview1 adapters: return exact same set of rights as wasi-common
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We have three preview1 implementations in tree:
wasi-commonwasi-preview1-component-adapterwasmtime-wasi::preview2::preview1This PR makes all of them report the exact same set of rights for directories.
wasi-libc based userlands (e.g. wasi-sdk, tinygo, some parts of rust std, and others!) will sometimes check whether they have a preview1 Right to perform an import function call, and return early if they do not.
Last attempt at adjusting how we report Rights #6463
hard-coded the set of rights in wasi-common. That PR also added a wasi-test
path_open_preopenthat was intended to check whether wasi-libc's expectations were met. This test focused on the bug report we had wasi-libc around opening directories, and short of testing for the full expected set or rights.We got a bug report on zulip that tinygo, which uses wasi-libc, failed in the go call
os.Create: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Problem.20with.20WasiCtxBuilder.2Epush_preopened_dir.20for.20component . It appeared this was getting rejected in wasi-libc, using the rights reported from the wasi-preview1-component-adapter.To avoid chasing these individual wasi-libc behaviors much further, I decided to add the expectation of the set of rights to
path_open_preopen, and fixwasi-preview1-component-adapterandwasmtime-wasi::preview2::preview1to always report those rights. This does mean duplicating that list of rights in a few more places in the source code, but theres no good way to do code sharing among these crates because the constants are coming from different crates/binding generators across these projects.I'd love for this to be the last time we have to kick the Rights can down the road. However, I'm now paranoid that, even with directories taken care of, we will run into the a similar problem with wasi-libc's expectation of file rights. I believe the behavior for file rights is consistent across all three implementations, so since we haven't gotten any file related bug reports since #6463 I am hopeful we have it right everywhere.