Hi,
On Fri, Oct 09, 2020 at 10:50:39AM +0200, Pablo Neira Ayuso wrote:
[...]
> Semantics for this are: Flush out _everything_ (existing rules and
> non-chains) but only leave existing basechain policies in place as is.
>
> I wonder if this is intentional or a side effect of the --noflush support.
>
> I'm Cc'ing Jozsef, maybe he remembers. Because you're reaching my
> boundaries on the netfilter history for this one :-)
FWIW, I searched git history and can confirm the given behaviour is like
that at least since Dec 2000 and commit ae1ff9f96a803 ("make
iptables-restore and iptables-save work again!")!
iptables-legacy-restore does:
| if (noflush == 0) {
| DEBUGP("Cleaning all chains of table '%s'\n",
| table);
| cb->for_each_chain(cb->flush_entries, verbose, 1,
| handle);
|
| DEBUGP("Deleting all user-defined chains "
| "of table '%s'\n", table);
| cb->for_each_chain(cb->delete_chain, verbose, 0,
| handle);
| }
(Third parameter to for_each_chain decides whether builtins are included or
not.)
I guess fundamentally this is due to legacy design which keeps builtin
chains in place at all times. We could copy that in iptables-nft, but I
like the current design where we just delete the whole table and start
from scratch.
Florian made a related remark a while ago about flushing chains with
DROP policy: He claims it is almost always a mistake and we should reset
the policy to ACCEPT in order to avoid people from locking themselves
out. I second that idea, but am not sure if such a change is tolerable
at all.
Cheers, Phil
