[PR #1661] [CLOSED] fix: reject directory paths for the Wakaru limiter and mitmdump #4733

New issue

Closed

opened 2026-10-31 00:54:29 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:54:29 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/1661
Author: @Fazmin
Created: 10/11/2026
Status: ❌ Closed

Base: main ← Head: fix/configured-command-regular-files

📝 Commits (1)

a533aaa fix: reject directory paths for the Wakaru limiter and mitmdump

📊 Changes

4 files changed (+55 additions, -2 deletions)

View changed files

➕ src/browser/history/MitmproxyCaptureAdapter.test.ts (+25 -0)
📝 src/browser/history/MitmproxyCaptureAdapter.ts (+3 -1)
📝 src/javascript/recovery/WakaruCommand.test.ts (+24 -0)
📝 src/javascript/recovery/WakaruCommand.ts (+3 -1)

📄 Description

Summary

REA_JAVASCRIPT_PRLIMIT_COMMAND (the Wakaru resource limiter) and REA_MITMDUMP_COMMAND are accepted at admission when they point at a directory. Both now require a regular file, as #751 did for the firmware engine and limiter. A misconfigured path is then refused up front with the existing capability refusal, which names the path. No issue is linked; this applies an existing, merged fix to two sibling paths.

Problem and expected behavior

Trigger (Linux): set REA_JAVASCRIPT_PRLIMIT_COMMAND or REA_MITMDUMP_COMMAND to an existing directory.
Violated invariant: a configured executable is a launchable regular file. Both sites checked only access(path, X_OK) (R_OK | X_OK for mitmdump), which a searchable directory passes. The firmware and EVMole limiters, and the configured firmware engines, already add stat().isFile() (#751).
Before: resolveWakaruCommand and MitmproxyCaptureAdapter.command return the directory as the command or limiter to launch. The failure is deferred until the process launch, after admission has succeeded.
After: both refuse at admission with AnalysisCapabilityUnavailableError, and the reason names the path:
- "Configured Wakaru or util-linux prlimit is unavailable: Resource limiter is not a regular file: "
- "Configured mitmdump executable is unavailable: ."

Change and scope

src/javascript/recovery/WakaruCommand.ts: after the limiter X_OK check, require stat(limiter).isFile(). The configured Wakaru command itself already reads through fingerprintRecoveryFile, which accepts only regular files, so it is unchanged.
src/browser/history/MitmproxyCaptureAdapter.ts: inside the existing try, require stat(command).isFile(). The existing catch turns the failure into the same refusal.

Symlinks to a real executable still pass, because stat follows links. Platform gating and error types are unchanged.

Contract and boundary impact

Semantic owner and earliest changed stage: admission of configured external commands (Wakaru recovery, mitmproxy capture decoding)
CLI and MCP/tool-catalog contract: none; the existing capability_unavailable outcome now covers directories
Provider, bridge, target-format, or platform compatibility: Linux only; both code paths already refuse other hosts before this check
Evidence, artifact, provenance, or reconstruction contract: none
Process execution, authorization, cleanup, or containment impact: a directory is no longer handed to the process launcher
Generated metadata, package, or installation impact: none

Evidence and regression coverage

Tests added or updated:
- src/javascript/recovery/WakaruCommand.test.ts: a directory limiter is refused with AnalysisCapabilityUnavailableError naming the path. Linux x64 only, matching resolveWakaruCommand's host gate.
- src/browser/history/MitmproxyCaptureAdapter.test.ts: a directory REA_MITMDUMP_COMMAND is refused the same way. Linux only, following src/firmware/FirmwareCommand.test.ts.

Base reproduction: I worked on macOS, where both new tests are skipped. To exercise the Linux-gated paths, I imported the built modules into a Node script and set process.platform/process.arch to linux/x64 after import:

Input	Base	This PR
Wakaru limiter = directory	resolved	refused, "…Resource limiter is not a regular file: "
Wakaru limiter = regular executable	resolved	resolved
mitmdump = directory	resolved	refused, "Configured mitmdump executable is unavailable: ."
mitmdump = regular executable	resolved	resolved

Remaining proof gaps: the new tests were not run on a real Linux host locally; Linux CI covers them. No real Wakaru or mitmdump was used.

Validation performed

All commands ran on macOS (arm64) with Node 24.18.0 and npm 11.16.0:

npm run test:local -- src/javascript/recovery/WakaruCommand.test.ts: 7 passed, 1 skipped (the new Linux x64 case).
npm run test:local -- src/browser/history/MitmproxyCaptureAdapter.test.ts: 1 skipped (Linux only).
npm run verify:test-discovery: all 795 test files discovered exactly once.
npm run check: passed.
The faked-Linux probe against npm run build:cached output for base and fixed revisions: results shown above.

Compatibility, safety, and release

Breaking changes or migration steps: none; a directory never worked as either executable
Real Hopper/Ghidra, browser, or OS coverage: no real Linux run locally; relies on Linux CI for the new tests
Package or release metadata impact: none
Security, privacy, process, or containment review: the change narrows what is launched; nothing new is executed

Review checklist

This PR addresses a concrete problem or an agreed enhancement.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/1661 **Author:** [@Fazmin](https://github.com/Fazmin) **Created:** 10/11/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/configured-command-regular-files` --- ### 📝 Commits (1) - [`a533aaa`](https://github.com/morluto/rea/commit/a533aaaca07fbb41b111634141e37a55a7ab4a8d) fix: reject directory paths for the Wakaru limiter and mitmdump ### 📊 Changes **4 files changed** (+55 additions, -2 deletions) <details> <summary>View changed files</summary> ➕ `src/browser/history/MitmproxyCaptureAdapter.test.ts` (+25 -0) 📝 `src/browser/history/MitmproxyCaptureAdapter.ts` (+3 -1) 📝 `src/javascript/recovery/WakaruCommand.test.ts` (+24 -0) 📝 `src/javascript/recovery/WakaruCommand.ts` (+3 -1) </details> ### 📄 Description ## Summary `REA_JAVASCRIPT_PRLIMIT_COMMAND` (the Wakaru resource limiter) and `REA_MITMDUMP_COMMAND` are accepted at admission when they point at a directory. Both now require a regular file, as #751 did for the firmware engine and limiter. A misconfigured path is then refused up front with the existing capability refusal, which names the path. No issue is linked; this applies an existing, merged fix to two sibling paths. ## Problem and expected behavior - **Trigger (Linux):** set `REA_JAVASCRIPT_PRLIMIT_COMMAND` or `REA_MITMDUMP_COMMAND` to an existing directory. - **Violated invariant:** a configured executable is a launchable regular file. Both sites checked only `access(path, X_OK)` (`R_OK | X_OK` for mitmdump), which a searchable directory passes. The firmware and EVMole limiters, and the configured firmware engines, already add `stat().isFile()` (#751). - **Before:** `resolveWakaruCommand` and `MitmproxyCaptureAdapter.command` return the directory as the command or limiter to launch. The failure is deferred until the process launch, after admission has succeeded. - **After:** both refuse at admission with `AnalysisCapabilityUnavailableError`, and the reason names the path: - "Configured Wakaru or util-linux prlimit is unavailable: Resource limiter is not a regular file: <path>" - "Configured mitmdump executable is unavailable: <path>." ## Change and scope - **`src/javascript/recovery/WakaruCommand.ts`:** after the limiter `X_OK` check, require `stat(limiter).isFile()`. The configured Wakaru command itself already reads through `fingerprintRecoveryFile`, which accepts only regular files, so it is unchanged. - **`src/browser/history/MitmproxyCaptureAdapter.ts`:** inside the existing `try`, require `stat(command).isFile()`. The existing `catch` turns the failure into the same refusal. Symlinks to a real executable still pass, because `stat` follows links. Platform gating and error types are unchanged. ## Contract and boundary impact - Semantic owner and earliest changed stage: admission of configured external commands (Wakaru recovery, mitmproxy capture decoding) - CLI and MCP/tool-catalog contract: none; the existing `capability_unavailable` outcome now covers directories - Provider, bridge, target-format, or platform compatibility: Linux only; both code paths already refuse other hosts before this check - Evidence, artifact, provenance, or reconstruction contract: none - Process execution, authorization, cleanup, or containment impact: a directory is no longer handed to the process launcher - Generated metadata, package, or installation impact: none ## Evidence and regression coverage - **Tests added or updated:** - `src/javascript/recovery/WakaruCommand.test.ts`: a directory limiter is refused with `AnalysisCapabilityUnavailableError` naming the path. Linux x64 only, matching `resolveWakaruCommand`'s host gate. - `src/browser/history/MitmproxyCaptureAdapter.test.ts`: a directory `REA_MITMDUMP_COMMAND` is refused the same way. Linux only, following `src/firmware/FirmwareCommand.test.ts`. - **Base reproduction:** I worked on macOS, where both new tests are skipped. To exercise the Linux-gated paths, I imported the built modules into a Node script and set `process.platform`/`process.arch` to `linux`/`x64` after import: | Input | Base | This PR | |---|---|---| | Wakaru limiter = directory | resolved | refused, "…Resource limiter is not a regular file: <dir>" | | Wakaru limiter = regular executable | resolved | resolved | | mitmdump = directory | resolved | refused, "Configured mitmdump executable is unavailable: <dir>." | | mitmdump = regular executable | resolved | resolved | - **Remaining proof gaps:** the new tests were not run on a real Linux host locally; Linux CI covers them. No real Wakaru or mitmdump was used. ## Validation performed All commands ran on macOS (arm64) with Node 24.18.0 and npm 11.16.0: - `npm run test:local -- src/javascript/recovery/WakaruCommand.test.ts`: 7 passed, 1 skipped (the new Linux x64 case). - `npm run test:local -- src/browser/history/MitmproxyCaptureAdapter.test.ts`: 1 skipped (Linux only). - `npm run verify:test-discovery`: all 795 test files discovered exactly once. - `npm run check`: passed. - The faked-Linux probe against `npm run build:cached` output for base and fixed revisions: results shown above. ## Compatibility, safety, and release - Breaking changes or migration steps: none; a directory never worked as either executable - Real Hopper/Ghidra, browser, or OS coverage: no real Linux run locally; relies on Linux CI for the new tests - Package or release metadata impact: none - Security, privacy, process, or containment review: the change narrows what is launched; nothing new is executed ## Review checklist - [x] This PR addresses a concrete problem or an agreed enhancement. - [x] The PR has one focused outcome and the title follows `type(scope): outcome`. - [x] Related issue is linked, or the reason for not linking one is stated above. - [x] Tests cover changed observable behavior and meaningful failure paths. - [x] Owning docs, contracts, and generated metadata are updated where needed. - [x] User-visible CLI/MCP changes include representative output. - [x] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 00:54:29 +00:00