Hi,
On Fri, 9 Oct 2020, Phil Sutter wrote:
> 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 :-)
Phil could dig it out from git history :-):
> 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.
I don't think such a change in the behaviour could properly be
communicated to the users, let alone notified them about such a change. It
could cause such subtle errors out there, which are hard to identify and
fix: they'll debug the rules/user chains and the very last the base rule
policy.
I know lots of effort went into backward compatibility, this should be
included there too.
Best regards,
Jozsef
-
E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxx
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
