mirror of
https://github.com/Control-D-Inc/ctrld.git
synced 2026-09-04 13:36:35 +02:00
Cuong Manh Le
891d5d9821
A host carrying orphaned WFP filters from a ctrld build that predates session-scoped ownership cannot recover on its own. In Firewall Mode those filters block all non-allowlisted outbound traffic machine-wide, which denies the replacement ctrld's own API bootstrap. API-managed startup then sits in the resolver-config retry loop forever and never reaches startWFPFilters, where the only stale-sublayer cleanup lived. Cleanup needs startup, startup needs the network, the network needs cleanup - the host stays locked out until a reboot. Add cleanupStaleDNSInterceptState() and call it early in run(), before the network-up wait and before the API preflight. On Windows it deletes ctrld's WFP sublayer, which takes its child filters with it, so a previous process's enforcement is gone before this process makes its first connection. Objects owned by a live session cannot be deleted, so a running ctrld is unaffected and "nothing to clean up" stays at debug level; an actual removal logs a warning, since it means a previous ctrld left machine-wide enforcement installed. macOS and the other platforms get no-op implementations: pf enforcement does not outlive the process, and startDNSIntercept already flushes the anchor and removes a stale anchor file before loading rules. The cleanup inside startWFPFilters stays as a second line of defense. The cleanup session is deliberately NOT dynamic. FwpmSubLayerDeleteByKey0 is documented to fail with FWP_E_DYNAMIC_SESSION_IN_PROGRESS when called from a dynamic session for an object that was not added in one, and the only orphans that can exist are exactly those: a ctrld predating session-scoped ownership added its sublayer statically. Anything a newer ctrld leaves behind is removed by the OS when its session ends. Opening this session dynamically would have made the cleanup a no-op in the one case it exists for, while still logging "no stale WFP state". A concurrently running ctrld is protected by documented ownership rather than by the child-filter question below: a session-scoped ctrld's sublayer belongs to a different dynamic session, so the delete fails with FWP_E_WRONG_SESSION. That matters because this call is made unconditionally at startup, in every intercept mode, so an interactive "ctrld run" alongside a healthy service reaches it. A ctrld predating session scoping has no such protection: it holds a non-dynamic sublayer, which is exactly what this targets and is indistinguishable from an orphan. Two guards cover that instead. Elevation, because opening a WFP engine and deleting ctrld's sublayer must not be reachable from an unprivileged local process - FwpmEngineOpen0 is expected to fail without elevation, but that is a property of the API rather than something this code checked, and it was the only barrier. And interactive invocation, since a service start is not interactive: the deadlock case still gets cleaned, while a hand-run "ctrld run" beside a live service does not strip its enforcement. That second guard requires positive evidence of absence - ctrldServiceLiveness answers unknown for an unreachable SCM or a service mid-stop, and unknown skips the cleanup exactly as running does, because "could not be observed" is not "not there". Both are asserted against the deletion itself, not only against the predicate: a caller-level test substitutes the WFP delete and the guard inputs, so a future change that stops consulting the guard, or consults it and deletes anyway, fails rather than staying green. Delete failures are no longer collapsed into "nothing to clean up". Only FWP_E_SUBLAYER_NOT_FOUND means that; any other code means state exists under our GUID that we could not remove, which is the lockout condition itself, so it is logged as a warning naming the code. Whether deleting the sublayer is sufficient is left explicitly UNRESOLVED rather than asserted. It is sufficient only if the delete also removes the filters inside it. FwpmSubLayerDeleteByKey0's Remarks say nothing about child filters either way, while object management states that an object cannot be deleted until everything referencing it has been - and FWP_E_IN_USE exists for that. Whether a filter's subLayerKey counts as such a reference is not documented, and this code cannot be exercised off-Windows, so the earlier claim that the delete "takes its child filters with it" is removed from the comment here and from docs/wfp-dns-intercept.md, which carried it from before this branch. The behaviour is safe under both readings: the delete is attempted, and FWP_E_IN_USE is reported rather than counted as success, so a support log distinguishes "cleared it" from "could not clear it". If a live Windows check shows FWP_E_IN_USE against orphaned filters, the cleanup must enumerate and delete those filters first. That is deliberately not written blind: FWPM_FILTER_ENUM_TEMPLATE0 has no sublayer field, so selecting ctrld's own filters means reading subLayerKey at a computed offset in FWPM_FILTER0, and getting that offset wrong would delete other software's filters - a worse failure than not cleaning up. Refs: https://learn.microsoft.com/en-us/windows/win32/api/fwpmu/nf-fwpmu-fwpmsublayerdeletebykey0 Refs: https://learn.microsoft.com/en-us/windows/win32/fwp/object-management
