Add a Firewall page, led by what is actually reachable
Listing zones and services is what firewall-cmd already does. The question it does not answer needs both halves at once: a port is reachable only when something is LISTENING on a network address AND the firewall permits it. On this machine that crossing is the whole story. The rules look unremarkable -- one zone, three services, a port range -- and what they mean is that PostgreSQL and Redis, published by rootless containers on every interface, are reachable by anyone on the network. Neither half says that alone, which is exactly how a tidy rules list coexists with an open database. Nothing was misconfigured: Fedora's default zone met podman's default publish behaviour. Ephemeral client sockets are excluded. A browser's outbound UDP port is indistinguishable from a service in ss, and listing twenty of them buried the two rows that mattered. Closing the port range names what it would cut off, by service, before doing it, and removing ssh says so when someone is connected over it. Rich rules are shown and never edited: a syntax is not a setting, but hiding it would misrepresent the configuration. The contract needed a recorded firewall, and the reason is worth keeping. The rule this page exists for cannot be tested against this machine -- its zone permits everything above 1024, so "listening" and "listening and permitted" give identical answers, and a blocked listener needs a port below 1024, which needs root. With the crossing deleted, the contract passed. It now runs against a fixture where two listeners are blocked, and catches it. Also here: polkit response files are written 0600 rather than at the default mask, the agent sweeps requests left by an instance that did not exit cleanly, and the write sweep waits for its harness to be ready instead of reporting the startup race as settings that failed. Claude-Session: https://claude.ai/code/session_01BRvzt4H8XXLPVH5MyYdk9L
This commit is contained in:
@@ -179,6 +179,30 @@ setting, and a settings page that half-supports a syntax is a trap.
|
||||
**This one is security-sensitive**: every change must state what it exposes,
|
||||
and closing a port someone is currently connected over should say so first.
|
||||
|
||||
**Landed 2026-08-19**, and it found something. The page leads with the crossing
|
||||
rather than the rules, because a port is reachable only when something is
|
||||
LISTENING on a network address AND the firewall permits it -- and on this
|
||||
machine that crossing is the whole story. The rules look unremarkable:
|
||||
FedoraWorkstation, three services, a port range. What they mean is that
|
||||
**PostgreSQL and Redis, published by rootless containers on every interface, are
|
||||
reachable by anyone on the network**. Neither half says that alone, which is why
|
||||
a rules-only panel can look tidy while a database sits open. Nothing was
|
||||
misconfigured; Fedora's default zone met podman's default publish behaviour.
|
||||
|
||||
Ephemeral client sockets are excluded. A browser's outbound UDP port is
|
||||
indistinguishable from a service in `ss`, and listing twenty of them buried the
|
||||
two rows that mattered -- 25 entries became 14.
|
||||
|
||||
Rich rules are shown and never edited: a syntax is not a setting, but hiding
|
||||
them would misrepresent the configuration.
|
||||
|
||||
**The contract needed a fixture, and the reason is worth keeping.** The rule
|
||||
this page exists for cannot be tested against this machine: its zone permits
|
||||
every port above 1024, so "listening" and "listening AND permitted" give
|
||||
identical answers, and producing a blocked listener needs a port below 1024,
|
||||
which needs root. With the crossing deleted the contract passed. It now runs
|
||||
against a recorded firewall where two listeners are blocked, and catches it.
|
||||
|
||||
### 3.2 Containers
|
||||
|
||||
podman is here and Storage already found 5.31 GB of reclaimable images. Running
|
||||
|
||||
Reference in New Issue
Block a user