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

[Pablo Neira Ayuso <pablo@netfilter.org>]

Cc'ing Jozsef.

On Fri, Oct 09, 2020 at 10:29:53AM +0200, Phil Sutter wrote:
> Hi Pablo,
> 
> On Thu, Oct 08, 2020 at 07:31:56PM +0200, Pablo Neira Ayuso wrote:
> > On Fri, Oct 02, 2020 at 01:44:36PM +0200, Arturo Borrero Gonzalez wrote:
> > > From: Pablo Neira Ayuso <pablo@netfilter.org>
> > > 
> > > Previous to this patch, the basechain policy could not be properly configured if it wasn't
> > > explictly set when loading the ruleset, leading to iptables-nft-restore (and ip6tables-nft-restore)
> > > trying to send an invalid ruleset to the kernel.
> > 
> > I have applied this with some amendments to the test file to cover
> > the --noflush case. I think this is a real problem there, where you
> > can combine to apply incremental updates to the ruleset.
> 
> Yes, at least I can imagine people relying upon this behaviour.
> 
> > For the --flush case, I still have doubts how to use this feature, not
> > sure it is worth the effort to actually fix it.
> 
> I even find it unintuitive as it retains state despite flushing.

So am I.

> But that is a significant divergence between legacy and nft:
> 
> | # iptables -P FORWARD DROP
> | # iptables-restore <<EOF
> | *filter
> | COMMIT
> | EOF
> | # iptables-save
>
> With legacy, the output is:
> 
> | *filter
> | :INPUT ACCEPT [0:0]
> | :FORWARD DROP [0:0]
> | :OUTPUT ACCEPT [0:0]
> | COMMIT
>
> With nft, there's no output at all. What do you think, should we fix
> that? If so, which side?

Looks like a variant of the same usecase.

So if basechains are not specified, then basechains policies are left
as is, but ruleset is flushed.

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 :-)

> > We can revisit later, you can rewrite this later Phil.
> 
> Sure, no problem.

Thanks.