Repository navigation
Firewall residues: an upgrade opens the pre-change port for one cycle, and a disabled surface still gets a rule #2436
Description
Activity
- added a commit that references this issue
on Aug 21, 2026 Fixed on
devby #2442, and my framing of residue 1 was wrong in the direction that matters.I wrote that the wrong-port rule "self-heals with one operator action, since the service's start-up check WARNs the exact command". The harm is the reverse.
--configure-firewallsweeps a surface's rules for every port —SurfaceRuleWildcardrewritesPerformanceMonitor Darling MCP (port 5152)to…(port *)— before opening the current one, and the installer runs it with the service, and therefore the managed store, stopped. On an upgrade of a moved-port box, the rule that wildcard matches is the working one. So the elevated verb the operator was told to run is what closes the live LAN surface.That is not a one-cycle inconvenience healed by running the command; running the command is the injury. Verified in source before accepting it.
So the sweep is now withheld when a run cannot vouch for what the surface is actually doing, and the installer re-reconciles after
Start-Serviceon upgrades only — a fresh install's ~2-minute initdb means a second call there could only re-print the fallback about a port that is correct by definition. The comment says plainly that this narrows the window rather than closing it.Residue 2 is closed rather than kept, and the deciding evidence was in the product rather than in reasoning:
DarlingMcpHostService's stop path already documents an admin removing the rule with--configure-firewall, and--disable-mcpsweeps it. The two verbs disagreed —--disable-mcpclosed the port and the next--configure-firewallre-opened it, and every upgrade runs that verb. So a deliberately disabled endpoint had its port re-opened by an upgrade. The "ready for when it is enabled" argument I offered is written down beside the decision as rejected, with why.Three review rounds each caught something real, and the first is worth recording: the sweep gate initially left the
Removehalf open, so an--enable-mcp-enabled box — which hitsOrigin == Fileon upgrade — would have had its stale filefalsedelete the live rule. The same class of mistake as the original defect, in the fix for it.One residue filed as #2445: the not-elevated branch prints a runnable command only for
Openplans, so aRemovethat wants its sweep hands over nothing and still returns 0. Pre-existing, but reachable more often now.
Two residues from #2414/#2432, which fixed the firewall verbs to resolve their port through the same resolver the endpoint binds on. Both were disclosed rather than folded in, and both are now visible instead of silent — which is why neither is urgent.
1. An in-place upgrade of a moved-port box opens the wrong port for one cycle
install-darling.ps1runs--configure-firewallat line 521 andStart-Serviceat line 534. The firewall is therefore configured before the service has started, which is correct on a fresh install —config_serviceis seeded from darling.json, so the file is the control plane's future answer and cannot be wrong.It is not correct on an upgrade of a box whose port was later changed in the Viewer. There the store already holds a different port, the service is stopped, and
--configure-firewallfalls back to the file. So the rule lands on the old port for one cycle.This was true before #2432 as well; what changed is that the fallback now says so, and the service's own start-up check WARNs the exact command to fix it. So it self-heals with one operator action rather than silently persisting.
Two ways to close it properly, and the choice is a real trade:
--configure-firewallagain afterStart-Service. Simple and correct, but the service's first start on a fresh install takes roughly two minutes (managed PostgreSQL bootstrap), so the installer either blocks on that or fires the second call without knowing the store is up.2. A rule is opened for a surface whose store flag says disabled
PlanFirewallRulesstill opens a rule for an exposed surface even when the store'smcp_enabled/web_enabledisfalse.That may be deliberate — a rule made ready for when the surface is enabled, so enabling it in the Viewer does not also require an elevated prompt. But it is the same shape as the stale rule #2432 just fixed: a firewall hole on a port nothing is serving. The difference is only that this one is on a port that might serve later.
Worth deciding explicitly. If it stays, the reasoning belongs in a comment where the next reader of
PlanFirewallRuleswill find it, because the sweep logic right beside it now argues the opposite way.