Stream: git-wasmtime

Topic: wasmtime / PR #14010 wasmtime-wasi: replace FilePerms, Di...


view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 20:57):

pchickey opened PR #14010 from pchickey:pch/preopen_mutate_bool to bytecodealliance:main:

Closes #14003

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 21:31):

:thumbs_up: alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 21:31):

:speech_balloon: alexcrichton created PR review comment:

I think this check can probably be removed entirely

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 21:59):

pchickey edited PR #14010:

Closes #14003

wasmtime-wasi accepted a pair of flag-sets, DirPerms and FilePerms, to set permissions on a preopened_dir. This permissions structure is specific to wasmtime-wasi's implementation, and is not specified by WASI. It is very poorly specified by its own documentation (a sum total of two doc strings on the DirPerms flags) and that documentation is inconsistent with the actual behavior - DirPerms::MUTATE without FilePerms::WRITE does not permit creating a new file.

The weird corner case created by DirPerms::MUTATE without FilePerms::WRITE has been the subject of multiple recent Wasmtime security advisories: GHSA-2r75-cxrj-cmph GHSA-4ch3-9j33-3pmj. I conducted an informal survey while remediating these, and AFAIK no production user of wasmtime-wasi is using that combination of permissions, nor write-without-read file permissions (covered by only one test), nor any of the other "weird" cases (any of FilePerms or DirPerms being empty).

The set that actually seems to be useful to wasmtime-wasi's users is either that an entire preopen is is read-write, or is read-only. So, this PR deletes DirPerms and FilePerms structures, and replaces them with a single boolean that permits mutation of the entire preopen, rendered as enum FsPerms { ReadOnly, ReadWrite }. This should hopefully make the permissions structure easy for both the implementation to enforce and for users to understand, and reduce the amount of time maintainers spend addressing security advisories for behaviors that nobody uses.

This PR was pretty mechanical:

Slightly non-obvious part of this change are in separate commits:

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 21:59):

pchickey updated PR #14010.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 21:59):

:memo: pchickey submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 21:59):

:speech_balloon: pchickey created PR review comment:

Thanks for catching that, fixed

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:00):

pchickey has marked PR #14010 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:00):

pchickey requested wasmtime-wasi-reviewers for a review on PR #14010.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:00):

pchickey requested rvolosatovs for a review on PR #14010.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:00):

pchickey requested wasmtime-core-reviewers for a review on PR #14010.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:00):

pchickey requested dicej for a review on PR #14010.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:03):

pchickey updated PR #14010.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:26):

:thumbs_up: dicej submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 28 2026 at 22:26):

:speech_balloon: dicej created PR review comment:

Looks like this comment was interrupted.

view this post on Zulip Wasmtime GitHub notifications bot (Jul 29 2026 at 00:02):

github-actions[bot] added the label wasi on PR #14010.


Last updated: Jul 29 2026 at 05:03 UTC