LC-210-GREPBAN-FULLPATH: net_guard grep-ban should match allow-list by full path, not basename #285

New issue

Closed

opened 2026-05-31 04:38:01 +02:00 by longjacksonle · 0 comments

longjacksonle commented

2026-05-31 04:38:01 +02:00

Owner

Problem

The LC-210 net_guard grep-ban matches its allow-list by basename, diverging from the deliberate full-relative-path convention the other three grep-bans (LC-152, LC-204, LC-206) adopted specifically to defeat basename collisions. It is safe today only because desktop/src/ is a flat directory with no subdirectories.

Where

desktop/src/net_guard.rs:430 - the ban iterates path.file_name() and checks membership in BAN_ALLOWED = ["net_guard.rs", "welcome.rs"] by basename.
Contrast: server/tests/lc152_no_raw_reqwest_in_src.rs, lc204_no_handrolled_migrations.rs, lc206_no_raw_image_decode_in_src.rs all match full relative paths, with an inline rationale that says basename matching is intentionally avoided so a future same-basename file in a subdirectory cannot inherit the exemption.

Failure mode / cost

The moment desktop/src/ grows a subdirectory, a file like foo/welcome.rs would silently inherit the raw-ureq exemption and could construct an unguarded outbound HTTP client without the ban firing. The guard would report green while its coverage quietly shrank. Low likelihood today (flat dir), but it is a latent hole that contradicts the other three bans' stated anti-basename rationale.

Proposed scope (small, fix-in-passing-sized)

Switch net_guard.rs's ban to match the allow-list by full path relative to desktop/src (mirror the LC-152/204/206 shape), with the same inline rationale comment.
Keep the load-bearing meta-test (ban_allow_list_entries_are_load_bearing) pointed at the same files.
No behavior change today; this closes the latent subdir hole and re-aligns all four grep-bans on one convention.

Acceptance

The desktop net_guard grep-ban matches allow-list entries by full relative path; a new same-basename file in a hypothetical desktop/src/<subdir>/ would NOT be exempted.

Anchored to LC-210 (desktop SSRF grep-ban). Severity: maintainability / latent-security; not urgent.

## Problem The LC-210 `net_guard` grep-ban matches its allow-list by **basename**, diverging from the deliberate full-relative-path convention the other three grep-bans (LC-152, LC-204, LC-206) adopted specifically to defeat basename collisions. It is safe today only because `desktop/src/` is a flat directory with no subdirectories. ## Where - `desktop/src/net_guard.rs:430` - the ban iterates `path.file_name()` and checks membership in `BAN_ALLOWED = ["net_guard.rs", "welcome.rs"]` by basename. - Contrast: `server/tests/lc152_no_raw_reqwest_in_src.rs`, `lc204_no_handrolled_migrations.rs`, `lc206_no_raw_image_decode_in_src.rs` all match full relative paths, with an inline rationale that says basename matching is intentionally avoided so a future same-basename file in a subdirectory cannot inherit the exemption. ## Failure mode / cost The moment `desktop/src/` grows a subdirectory, a file like `foo/welcome.rs` would silently inherit the raw-`ureq` exemption and could construct an unguarded outbound HTTP client without the ban firing. The guard would report green while its coverage quietly shrank. Low likelihood today (flat dir), but it is a latent hole that contradicts the other three bans' stated anti-basename rationale. ## Proposed scope (small, fix-in-passing-sized) - Switch `net_guard.rs`'s ban to match the allow-list by full path relative to `desktop/src` (mirror the LC-152/204/206 shape), with the same inline rationale comment. - Keep the load-bearing meta-test (`ban_allow_list_entries_are_load_bearing`) pointed at the same files. - No behavior change today; this closes the latent subdir hole and re-aligns all four grep-bans on one convention. ## Acceptance The desktop `net_guard` grep-ban matches allow-list entries by full relative path; a new same-basename file in a hypothetical `desktop/src/<subdir>/` would NOT be exempted. Anchored to LC-210 (desktop SSRF grep-ban). Severity: maintainability / latent-security; not urgent.