wasmtime / PR #15059 perfmap: Don't follow a symlink at /... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #15059 perfmap: Don't follow a symlink at /...

Wasmtime GitHub notifications bot (Oct 29 2026 at 13:50):

netliomax25-code opened PR #15059 from netliomax25-code:perfmap-no-follow-symlink to bytecodealliance:main:

The perfmap profiling agent opens /tmp/perf-<pid>.map with create(true) and append(true), which follows symlinks. The path is predictable and /tmp is world-writable, so another local user can create /tmp/perf-<pid>.map ahead of time as a symlink to a file owned by whoever runs Wasmtime. When that user then runs with --profile=perfmap (or ProfilingStrategy::PerfMap), Wasmtime appends one line per compiled function to the symlink target with that user's permissions. The function names in those lines come from the module's name section, so part of what gets written is chosen by the module author.

Linux's fs.protected_symlinks=1 blocks following another user's symlink in a sticky directory, but that sysctl is not set everywhere, and macOS has no equivalent. On macOS, with a symlink to a scratch file in place, the target ended up with lines such as 0x104114000 10 x; touch /tmp/pwned.

Passing O_NOFOLLOW makes Engine::new fail with ELOOP in that situation instead of writing through the link. Behavior without a planted link should be unchanged. The jitdump agent writes ./jit-<pid>.dump in the current directory rather than a shared one, so it is left as is.

Testing:

New unit test profiling_agent::perfmap::tests::does_not_follow_symlink plants a symlink at the map path and checks that new() returns an error. It fails without the change and passes with it.

cargo test -p wasmtime --lib and cargo test --test all profiling:: pass on aarch64-apple-darwin. I was not able to build for Linux locally; O_NOFOLLOW and OpenOptionsExt::custom_flags are available on all unix targets.

Wasmtime GitHub notifications bot (Oct 29 2026 at 13:50):

netliomax25-code removed the review request for wasmtime-core-reviewers from PR #15059.

Wasmtime GitHub notifications bot (Oct 29 2026 at 13:50):

netliomax25-code requested pchickey for a review on PR #15059.

Wasmtime GitHub notifications bot (Oct 29 2026 at 13:50):

netliomax25-code requested wasmtime-core-reviewers for a review on PR #15059.

Wasmtime GitHub notifications bot (Oct 29 2026 at 16:46):

github-actions[bot] added the label wasmtime:api on PR #15059.

Wasmtime GitHub notifications bot (Oct 29 2026 at 17:32):

:cross_mark: pchickey closed without merge PR #15059.

Wasmtime GitHub notifications bot (Oct 29 2026 at 17:32):

pchickey commented on PR #15059:

It's not part of Wasmtime's threat model to consider that other users on the same operating system may be acting maliciously in a way that disturbs Wasmtime.

Wasmtime GitHub notifications bot (Oct 29 2026 at 17:40):

bjorn3 commented on PR #15059:

Why not? That would make it unsafe to use wasmtime on shared systems like universities, right?

Wasmtime GitHub notifications bot (Oct 29 2026 at 17:54):

pchickey commented on PR #15059:

We have a finite amount of things we have energy to care about, and using unix accounts as a security boundary isn't one of them. Wasmtime is in production in a great variety of production environments across many BA members as well as many non-members, and if any of them consider this part of their threat model they can talk to the TSC and Wasmtime maintainers, but until then I can't spend time and attention on PRs about things that don't matter, and not add the cost of that complexity to our codebase.

Wasmtime GitHub notifications bot (Oct 29 2026 at 17:55):

pchickey edited a comment on PR #15059:

We have a finite amount of things we have energy to care about, and using unix accounts as a security boundary isn't one of them. Wasmtime is in production in a great variety of production environments across many BA members as well as many non-members, and if any of them consider this part of their threat model they can talk to the TSC and Wasmtime maintainers about how to apply labor to our project so that new threat model can be engineered for properly. Until then I can't spend time and attention on PRs about things that don't matter, and not add the cost of that complexity to our codebase.

Wasmtime GitHub notifications bot (Oct 29 2026 at 17:55):

pchickey edited a comment on PR #15059:

We have a finite amount of things we have energy to care about, and using unix accounts as a security boundary isn't one of them. Wasmtime is in production in a great variety of production environments across many BA members as well as many non-members, and if any of them consider this part of their threat model they can talk to the TSC and Wasmtime maintainers about how to apply labor to our project so that new threat model can be engineered for properly. Until then I can't spend time and attention on PRs about things that don't matter to any users, and not add the cost of that complexity to our codebase.

Last updated: Oct 31 2026 at 23:03 UTC