From: Thomas Haller <thaller@redhat.com>
To: Phil Sutter <phil@nwl.cc>
Cc: NetFilter <netfilter-devel@vger.kernel.org>,
Pablo Neira Ayuso <pablo@netfilter.org>
Subject: Re: [nft v2 PATCH 1/3] nftables: add input flags for nft_ctx
Date: Tue, 18 Jul 2023 11:05:45 +0200 [thread overview]
Message-ID: <98298234d31a02f10cfd022ce59140db80ca8750.camel@redhat.com> (raw)
In-Reply-To: <ZLEgaNIH/ZD4hnf3@orbyte.nwl.cc>
On Fri, 2023-07-14 at 12:16 +0200, Phil Sutter wrote:
> On Fri, Jul 14, 2023 at 10:48:51AM +0200, Thomas Haller wrote:
> [...]
> > +=== nft_ctx_input_get_flags() and nft_ctx_input_set_flags()
> > +The flags setting controls the input format.
>
> Note how we turn on JSON input parsing if JSON output is enabled.
>
> I think we could tidy things up by introducing NFT_CTX_INPUT_JSON and
> flip it from nft_ctx_output_set_flags() to match NFT_CTX_OUTPUT_JSON
> for
> compatibility?
Hi Phil,
The doc says:
doc/libnftables.adoc:NFT_CTX_OUTPUT_JSON::
doc/libnftables.adoc- If enabled at compile-time, libnftables accepts input in JSON format and is able to print output in JSON format as well.
doc/libnftables.adoc- See *libnftables-json*(5) for a description of the supported schema.
doc/libnftables.adoc- This flag controls JSON output format, input is auto-detected.
which is a bit inaccurate, as JSON is auto-detect if-and-only-if
NFT_CTX_OUTPUT_JSON is set.
src/libnftables.c: if (nft_output_json(&nft->output))
src/libnftables.c- rc = nft_parse_json_buffer(nft, nlbuf, &msgs, &cmds);
src/libnftables.c- if (rc == -EINVAL)
src/libnftables.c- rc = nft_parse_bison_buffer(nft, nlbuf, &msgs, &cmds,
src/libnftables.c- &indesc_cmdline);
I think, that toggling the input flag when setting an output flag
should not be done. It's confusing to behave differently depending on
the order in which nft_ctx_output_set_flags() and
nft_ctx_input_set_flags() are called. And it's confusing that setting
output flags would mangle input flags.
And for the sake of backwards compatibility, the current behavior must
be kept anyway. So there is only a place for overruling the current
automatism via some NFT_CTX_INPUT_NO_JSON (aka
NFT_CTX_INOUT_FORCE_BISON) or NFT_CTX_INPUT_FORCE_JSON flags, like
try_json = TRUE;
try_bison = TRUE;
if (nft_ctx_input_get_flags(ctx) & NFT_CTX_INPUT_NO_JSON)
try_json = FALSE;
else if (nft_ctx_input_get_flags(ctx) & NFT_CTX_INPUT_FORCE_JSON)
try_bison = FALSE;
else if (nft_output_json(&ctx->output)) {
/* try both, JSON first */
} else
try_json = FALSE;
if (try_json)
rc = nft_parse_json_buffer(nft, nlbuf, &msgs, &cmds);
if (try_bison && (!try_json || rc == -EINVAL))
rc = nft_parse_bison_buffer(nft, nlbuf, ...);
This would not require to mangle input flags during
nft_ctx_output_set_flags().
But I find those two flags unnecessary. Both can be added any time
later when needed. The addition of nft_ctx_input_set_flags() does not
force a resolution now.
Also, depending on the semantics, I don't understand how
NFT_CTX_INPUT_JSON extends the current behavior in a backward
compatible way. The default would be to not have that flag set, which
already means to enable JSON parsing depending on NFT_CTX_OUTPUT_JSON.
If NFT_CTX_INPUT_JSON merely means to explicitly enable JSON input,
then that is already fully configurable today. Having this flag does
not provide something new (unlike NO_JSON/FORCE_BISON or FORCE_JSON
flags would).
Thomas
next prev parent reply other threads:[~2023-07-18 9:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 17:46 [nft PATCH] nftables: add flag for nft context to avoid blocking getaddrinfo() Thomas Haller
2023-07-10 17:58 ` Pablo Neira Ayuso
2023-07-14 8:48 ` [nft v2 PATCH 1/3] nftables: add input flags for nft_ctx Thomas Haller
2023-07-14 8:48 ` [nft v2 PATCH 2/3] nftables: add input flag NFT_CTX_INPUT_NO_DNS to avoid blocking getaddrinfo() Thomas Haller
2023-07-14 10:07 ` Phil Sutter
2023-07-18 9:12 ` Thomas Haller
2023-07-14 8:48 ` [nft v2 PATCH 3/3] py: add input_{set,get}_flags() API to helpers Thomas Haller
2023-07-14 9:59 ` Phil Sutter
2023-07-18 10:07 ` Thomas Haller
2023-07-14 10:16 ` [nft v2 PATCH 1/3] nftables: add input flags for nft_ctx Phil Sutter
2023-07-18 9:05 ` Thomas Haller [this message]
2023-07-18 9:33 ` Phil Sutter
2023-07-18 10:31 ` Thomas Haller
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=98298234d31a02f10cfd022ce59140db80ca8750.camel@redhat.com \
--to=thaller@redhat.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).