All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Phil Sutter <phil@nwl.cc>,
	Arturo Borrero Gonzalez <arturo@netfilter.org>,
	netfilter-devel@vger.kernel.org, kadlec@netfilter.org
Subject: Re: [iptables PATCH] iptables-nft: fix basechain policy configuration
Date: Fri, 9 Oct 2020 10:50:39 +0200	[thread overview]
Message-ID: <20201009085039.GB7851@salvia> (raw)
In-Reply-To: <20201009082953.GD13016@orbyte.nwl.cc>

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.

  reply	other threads:[~2020-10-09  8:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 11:44 [iptables PATCH] iptables-nft: fix basechain policy configuration Arturo Borrero Gonzalez
2020-10-02 12:07 ` Phil Sutter
2020-10-02 12:15   ` Pablo Neira Ayuso
2020-10-02 12:28     ` Phil Sutter
2020-10-02 12:47       ` Pablo Neira Ayuso
2020-10-02 13:31         ` Phil Sutter
2020-10-02 14:39           ` Pablo Neira Ayuso
2020-10-08 17:31 ` Pablo Neira Ayuso
2020-10-09  8:29   ` Phil Sutter
2020-10-09  8:50     ` Pablo Neira Ayuso [this message]
2020-10-09  9:37       ` Phil Sutter
2020-10-09 10:07         ` Reindl Harald
2020-10-09 10:14           ` Phil Sutter
2020-10-09 10:28             ` Reindl Harald
2020-10-09 10:37         ` Jozsef Kadlecsik
2020-10-09 12:04           ` Phil Sutter
2020-10-09 19:05             ` Jozsef Kadlecsik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201009085039.GB7851@salvia \
    --to=pablo@netfilter.org \
    --cc=arturo@netfilter.org \
    --cc=kadlec@netfilter.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=phil@nwl.cc \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.