Re: [PATCH v2 4/7] doc: add overall description of the ruleset evaluation

[Florian Westphal <fw@strlen.de>]

Christoph Anton Mitterer <mail@christoph.anton.mitterer.name> wrote:
> +  It accepts the packet only with respect to the current base chain. Any other
> +  base chain (or regular chain called by such) with a higher priority of the
> +  same hook as well as any other base chain (or regular chain called by such) of
> +  any later hook may however still ultimately *drop* (which might also be done
> +  via verdict-like statements that imply *drop*, like *reject*) the packet with
> +  an according verdict (with consequences as described below for *drop*).

...

> +  Thus and merely from netfilter’s point of view, a packet is only ultimately
> +  accepted if none of the chains (regardless of their tables) that are attached
> +  to any of the respectively relevant hooks issues a *drop* verdict (be it
> +  explicitly or implicitly by policy or via a verdict-like statement that
> +  implies *drop*, for example *reject*), which already means that there has to
> +  be at least one *accept* verdict (be it explicitly or implicitly by policy).
> +  All this applies analogously to verdict-like statements that imply *accept*,
> +  for example the NAT statements.

... I think this is too confusing and verbose.
packet ultimately passed: no drop verdict was issued.  Its all there is
to it, really.

> +* A *drop* verdict (including an implict one via the base chain’s policy)
> +  immediately ends the evaluation of the whole ruleset and ultimately drops the
> +  packet.
> +  Unlike with an *accept* verdict, no further chains of any hook and regardless
> +  of their table get evaluated and it’s therefore not possible to have an *drop*
> +  verdict overruled.

This is fine.

> +  Thus, if any base chain uses drop as its policy, the same base chain (or any
> +  regular chain directly or indirectly called by it) must accept a packet or it
> +  is ensured to be ultimately dropped by it.
> +  All this applies analogously to verdict-like statements that imply *drop*,
> +  for example *reject*.

Same.

> +* Given the semantics of *accept*/*drop* and only with respect to the utlimate
> +  decision of whether a packet is accepted or dropped, the ordering of the
> +  various base chains per hook via their priorities matters only in so far, as
> +  any of them modifies the packet or its meta data and that has an influence on
> +  the verdicts issued by the chains – other than that, the ordering shouldn’t
> +  matter (except for performance and other side effects).
> +  It also means that short-circuiting the ultimate decision is only possible via
> +  *drop* verdicts (respectively verdict-like statements that imply *drop*, for
> +  example *reject*).

Maybe rework the *accept* part to say that the packet moves on to the
next hook?  (As opposed to *drop*, which is final).

I think almost all of the overrule talk comes from this distinction (or
lack thereof).