Firewall panel advertises service-name rules the backend rejects #9

New issue

Closed

opened 2026-09-09 09:08:50 +08:00 by Breadway · 2 comments

Breadway commented

2026-09-09 09:08:50 +08:00

Owner

Broken out from ECO-15 (bread-ecosystem audit, 2026-09-05). Verified still present on main as of 2026-09-09.

The Firewall panel UI and its validator disagree:

frontend/src/lib/views/Firewall.svelte:102 sets the "Add rule" hint to: e.g. "8080/tcp", "22/tcp", or a service name like "OpenSSH". and the input placeholder (line 104) is port/proto or service name.
src/src/commands/firewall.rs valid_firewall_rule is port-only by design (kept strict from f7b114f). Its own test asserts !valid_firewall_rule("OpenSSH") (line 165).

So a user who follows the UI hint and types OpenSSH gets a rejection.

Pick one:

Loosen the backend to util::valid_cli_value (still argv-safe: blocks flags, ;, and control characters) and let ufw resolve the service name, or
Drop the service-name text from the hint and the placeholder, keeping the validator port-only.

BSET-5's PR body flagged this as an unresolved product call. The cheapest option is removing the service-name wording (one line each in Firewall.svelte). Whichever way it goes, the UI copy and the validator should agree, and the firewall.rs test should reflect the decision.

Broken out from ECO-15 (bread-ecosystem audit, 2026-09-05). Verified still present on main as of 2026-09-09. The Firewall panel UI and its validator disagree: - `frontend/src/lib/views/Firewall.svelte:102` sets the "Add rule" hint to: `e.g. "8080/tcp", "22/tcp", or a service name like "OpenSSH".` and the input placeholder (line 104) is `port/proto or service name`. - `src/src/commands/firewall.rs` `valid_firewall_rule` is port-only by design (kept strict from f7b114f). Its own test asserts `!valid_firewall_rule("OpenSSH")` (line 165). So a user who follows the UI hint and types `OpenSSH` gets a rejection. Pick one: 1. Loosen the backend to `util::valid_cli_value` (still argv-safe: blocks flags, `;`, and control characters) and let ufw resolve the service name, or 2. Drop the service-name text from the hint and the placeholder, keeping the validator port-only. BSET-5's PR body flagged this as an unresolved product call. The cheapest option is removing the service-name wording (one line each in `Firewall.svelte`). Whichever way it goes, the UI copy and the validator should agree, and the `firewall.rs` test should reflect the decision.

Breadway added the

enhancement

label

2026-09-09 09:08:51 +08:00

Breadway referenced this issue from a commit

2026-09-09 19:43:51 +08:00

fix(firewall): align add-rule hint with the port-only validator

Breadway referenced this issue from a pull request that will close it,

2026-09-09 19:44:01 +08:00

Firewall panel advertises service-name rules the backend rejects #10

Breadway commented

2026-09-09 19:44:09 +08:00

Author

Owner

PR: #10

Took option 2: updated the "Add rule" hint and input placeholder in frontend/src/lib/views/Firewall.svelte to describe the port/proto forms valid_firewall_rule actually accepts, instead of advertising service names the port-only validator rejects. No backend change; valid_firewall_rule and its !valid_firewall_rule("OpenSSH") test already match this copy. Verified with npm run build and npm run check (0 errors, 0 warnings).

Went with option 2 rather than loosening the validator because keeping it port-only is a deliberate argv-safety measure (f7b114f); supporting service names is a security-sensitive product decision better handled as its own feature.

PR: https://git.breadway.dev/Breadway/bos-settings/pulls/10 Took option 2: updated the "Add rule" hint and input placeholder in `frontend/src/lib/views/Firewall.svelte` to describe the port/proto forms `valid_firewall_rule` actually accepts, instead of advertising service names the port-only validator rejects. No backend change; `valid_firewall_rule` and its `!valid_firewall_rule("OpenSSH")` test already match this copy. Verified with `npm run build` and `npm run check` (0 errors, 0 warnings). Went with option 2 rather than loosening the validator because keeping it port-only is a deliberate argv-safety measure (f7b114f); supporting service names is a security-sensitive product decision better handled as its own feature.

Breadway closed this issue

2026-09-11 11:01:34 +08:00

Breadway commented

2026-09-11 11:01:43 +08:00

Author

Owner

Reviewed and merged (squash, PR #10).

Acceptance criteria: make the UI hint and validator agree, and update the firewall.rs test if the behavior changes. Went with option 2 (drop the service-name wording from the hint and placeholder), which needed no backend change since valid_firewall_rule was already port-only and its test already asserted rejection of "OpenSSH". Minimal, correct, matches the issue's own cheapest-option recommendation. CI green, no conflicts.

Reviewed and merged (squash, PR #10). Acceptance criteria: make the UI hint and validator agree, and update the firewall.rs test if the behavior changes. Went with option 2 (drop the service-name wording from the hint and placeholder), which needed no backend change since valid_firewall_rule was already port-only and its test already asserted rejection of "OpenSSH". Minimal, correct, matches the issue's own cheapest-option recommendation. CI green, no conflicts.