fix(room): bound file parent traversal and preflight - #31
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: blocked before merge. Reviewed September 15, 2026, 11:42 PM ET / September 16, 2026, 03:42 UTC (Revision 19). ClawSweeper reviewWhat this changesThe PR bounds room-node file parent traversal, permits mutation-free preflight beneath an existing root, and adds registered-command filesystem coverage to CI. Merge readiness⛔ Blocked before merge - 1 item remains This remains a useful fix: current main retains both traversal defects, and no replacement was identified. The updated production-handler validation addresses the earlier proof request; no blocking patch defect was found. Priority: P2 Review scores
Verification
How this fits togetherRoom nodes expose file commands when their board supplies an approved storage root. Incoming file-write requests pass through path validation and optional parent creation before returning a preflight result or writing decoded content. flowchart TD
A[Board storage root] --> C[File command handler]
B[File write request] --> C
C --> D[Validate path and parents]
D --> E{Preflight only}
E -->|Yes| F[Return validation result]
E -->|No| G[Create parents and write file]
Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Keep the bounded traversal in the existing file-command owner, with registered-handler regression coverage protecting root recovery and mutation-free preflight. Do we have a high-confidence way to reproduce the issue? Yes: register an existing root, remove it, then request a direct-child write with createParents; current-main source proves the out-of-bounds starting position. The PR reports the corresponding sanitizer failure, but this review did not execute it. Is this the best way to solve the issue? Yes: correcting the two boundary conditions in the existing implementation is a narrow repair, and the new harness exercises the actual handler rather than duplicating its traversal. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning medium; reviewed against 7b8b32db7f12. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (18 earlier review cycles; latest 8 shown)
|
Recreate missing roots before walking descendants and include the existing root in side-effect-free preflight. Exercise the registered file.write handler with real JSON, crypto and filesystem operations under ASan/UBSan. Co-authored-by: Sebastien Tardif <sebtardif@ncf.ca>
b769f01 to
07638b6
Compare
file.writecould walk past its parent path's terminating NUL when the configured storage root disappeared after command registration. Parent creation now starts at the root boundary, safely recreating the root before any missing descendants. The related preflight traversal now checks the existing root itself, socreateParents: truecan validate a new nested path without creating directories or files.This retains @SebTardif's reported fix and contributor credit, replaces the standalone walk helper with the bounded production traversal, and adds registered-command regression coverage. No public API, dependency version, or release changes.
Validation:
PARENT_NOT_FOUND; nested root recovery returnedWRITE_ERROR.run_file_host_tests.pypasses all four scenarios with ASan/UBSan and patterned stack initialization. It compiles the complete production file-command source with real cJSON and mbedTLS, uses a synthetic Node registration boundary, and executes real temporary filesystem writes. It verifies content/SHA-256, mutation-free preflight, missing-parent errors, and symlink rejection.actionlintandgit diff --checkpass. Independent autoreview is clean through P2.07638b667b83c23b757861e694bea19f5ca19acd. Physical SD-card removal has not been tested.