Re: [iptables PATCH] iptables-nft: fix basechain policy configuration

[Phil Sutter <phil@nwl.cc>]

Hi,

On Fri, Oct 09, 2020 at 12:37:25PM +0200, Jozsef Kadlecsik wrote:
[...]
> I know lots of effort went into backward compatibility, this should be 
> included there too.

Certainly doable. Some hacking turned into quite a mess, though:

When restoring without '--noflush', a chain cache is needed - simply
doable by treating NFT_CL_FAKE differently. Reacting upon a chain policy
of '-' is easy, just lookup the existing chain's policy from cache and
use that. Things then become ugly for not specified chains:
'flush_table' callback really deletes the table. So one has to gather
the existing builtin chains first, check if their policy is non-default
and restore those. If they don't exist though, one has to expect for
them to occur when refreshing the transaction (due to concurrent ruleset
change). So the batch jobs have to be created either way and just set to
'skip' if either table or chain doesn't exist or the policy is ACCEPT.

If alternatively I decide to drop the table delete in 'flush_table', I
need to decide whether a builtin chain should be deleted or not, based
on its policy - which may change, so when refreshing transaction I would
have to turn a chain delete job into a flush rules one. Not nice, so
don't delete builtin chains in the first place. But the next obstacle
comes with user-defined chains: Deleting the existing ones, no problem -
cache is there. But when refreshing the transaction, new ones have to be
expected, so new jobs created.

The potential need to refresh a transaction is really causing
head-aches and the simple approach of dropping the table helped quite a
bit with that. Maybe I could implement some kernel bits to make things
simpler, like "delete all non-base chains" or "create chain if not
existing". But first I need more coffee. %)

Cheers, Phil