netfs: check the caller when there is one to check

An announce names no peer -- at that moment nobody has called -- so
matchrule skipped every rule naming an address, and "deny=in
ip=1.2.3.4" did nothing at all in namespace mode while doing something
real at the packet layer.  The code said so and called it right:

	A rule naming a peer therefore cannot apply to an announce,
	which is right: at this point there is no peer to name.

Right about the announce, wrong about the connection.  A rule that
silently does nothing is the failure this program refuses to accept
from a mistyped attribute -- fw will not start rather than run with
"prot=tcp" ignored -- and it should not accept it from itself.

So the peer is asked about at listen time, when there is one.  The fd
that listen yields is the new conversation's ctl file; its number reads
out of it at offset 0, so the program's own read, the one listen(2)
makes to learn the same number, still sees it.  remote and local give
the peer and the port announced.  If the rules refuse, the connection
is hung up and the open fails, and the program never has it.

The handshake has already happened by then: the kernel answered before
listen returned, and no filter at this altitude can prevent that.  That
is the difference between a rule that is late and a rule that is
decorative, and it is worth the distinction.

Two checks, on the same pair of rule sets, differing only in whether
the caller is refused; both fail against the previous netfs.c.  They
read /sys/log/fw as a difference rather than a total: the caller's port
is ephemeral, so nothing in the line belongs to this run, and the log
keeps what earlier runs put there.  The machine's own address stands in
for a peer, since this one has no loopback configured -- announcing
127.0.0.1 gets "not a local IP address", and announcing a bare port
binds to :: and never sees a v4 call at all.

66 pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions