From: Phil Sutter <phil@nwl.cc>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, netfilter-devel@vger.kernel.org
Subject: Re: [nft PATCH v2 0/4] xt: Implement dump and restore support
Date: Fri, 18 Nov 2022 10:55:04 +0100 [thread overview]
Message-ID: <Y3dWeMdYowQ4aEeT@orbyte.nwl.cc> (raw)
In-Reply-To: <Y3dTDj6OgEkyP/WD@salvia>
On Fri, Nov 18, 2022 at 10:40:30AM +0100, Pablo Neira Ayuso wrote:
> On Thu, Nov 17, 2022 at 10:13:47PM +0100, Florian Westphal wrote:
> > Phil Sutter <phil@nwl.cc> wrote:
> > > If nft can't translate a compat expression, dump it in a format that can
> > > be restored later without losing data, thereby keeping the ruleset
> > > intact.
> >
> > Why? :-( This cements nft_compat.c forever.
> >
> > If we're goping to do it lets at least dump it properly,
> > i.e. nft ... add rule compat "-m conntrack --ctstate NEW".
>
> We might have to support this mixed syntax forever. I proposed this
> long long time ago, when nftables was supporting ~25% of the iptables
> feature-set. These days, where they are almost on par (actually
> nftables being a lot more expressive than iptables), I am not sure it
> makes sense to follow this path anymore.
>
> Unless you refer to dumping a listing which nft cannot load as a way
> to provide a listing that is comprehensible, but that cannot be loaded
> by the user.
Or a big fat warning, but I fear anything that allows
| nft list ruleset | nft -f -
will simply be ignored until the problems become obvious.
> > At this time I'd rather like a time machine to prevent nft_compat.c from
> > getting merged :-(
>
> I agree we should have added native translations for iptables-nft
> sooner, but it was never a priority for anyone so far.
>
> This "forward compatibility" issue (pretending old tool versions can
> interpret new revisions / features loaded by newer tool versions) we
> are trying to deal is hard, we already discussed none of the other
> existing tooling (ethtool, iproute2, etc.) supports for this.
>
> If you prefer to go for the _USERDATA area as a last resort, I'm OK
> with it, this requires no kernel patches, and it will be used only for
> the "forward compatibility" scenario (last resort)
>
> We can also resort on displaying the raw expressions, so the user gets
> a meaningful output that cannot be loaded again.
>
> I think this more or less a summary of what we discussed in the NFWS.
Pablo, I think you're mixing up two things here:
This "support dump and load of compat expression" feature is to sanitize
the current situation with up to date iptables and nftables.
The forward compat (you were right about the direction) issue is mostly
about iptables-nft vs. itself in an older version.
Cheers, Phil
next prev parent reply other threads:[~2022-11-18 9:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 17:45 [nft PATCH v2 0/4] xt: Implement dump and restore support Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 1/4] xt: Delay libxtables access until translation Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 2/4] xt: Implement dump and restore support Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 3/4] xt: Put match/target translation into own functions Phil Sutter
2022-11-17 17:45 ` [nft PATCH v2 4/4] xt: Detect xlate callback failure Phil Sutter
2022-11-17 21:13 ` [nft PATCH v2 0/4] xt: Implement dump and restore support Florian Westphal
2022-11-18 9:40 ` Pablo Neira Ayuso
2022-11-18 9:55 ` Phil Sutter [this message]
2022-11-18 9:47 ` Phil Sutter
2022-11-18 10:11 ` Pablo Neira Ayuso
2022-11-18 10:42 ` Phil Sutter
2022-11-18 11:46 ` Florian Westphal
2022-11-18 12:12 ` Phil Sutter
2022-11-18 12:18 ` Pablo Neira Ayuso
2022-11-18 12:24 ` Phil Sutter
2022-11-18 13:34 ` Florian Westphal
2022-11-18 14:10 ` Pablo Neira Ayuso
2022-11-18 14:52 ` Phil Sutter
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=Y3dWeMdYowQ4aEeT@orbyte.nwl.cc \
--to=phil@nwl.cc \
--cc=fw@strlen.de \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/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.