From: Florian Westphal <fw@strlen.de>
To: Phil Sutter <phil@nwl.cc>
Cc: Florian Westphal <fw@strlen.de>,
Pablo Neira Ayuso <pablo@netfilter.org>,
netfilter-devel@vger.kernel.org
Subject: Re: [libnftnl RFC 2/2] expr: Introduce struct expr_ops::attr_policy
Date: Wed, 13 Dec 2023 21:20:35 +0100 [thread overview]
Message-ID: <20231213202035.GA6601@breakpoint.cc> (raw)
In-Reply-To: <20231213190222.3681-2-phil@nwl.cc>
Phil Sutter <phil@nwl.cc> wrote:
> Similar to kernel's nla_policy, enable expressions to inform about
> restrictions on attribute use. This allows the generic expression code
> to perform sanity checks before dispatching to expression ops.
>
> For now, this holds only the maximum data len which may be passed to
> nftnl_expr_set().
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> include/expr_ops.h | 5 +++++
> src/expr.c | 6 ++++++
> src/expr/bitwise.c | 11 +++++++++++
> src/expr/byteorder.c | 9 +++++++++
> src/expr/immediate.c | 9 +++++++++
> 5 files changed, 40 insertions(+)
>
> diff --git a/include/expr_ops.h b/include/expr_ops.h
> index 51b221483552c..6c95297bfcd58 100644
> --- a/include/expr_ops.h
> +++ b/include/expr_ops.h
> @@ -8,10 +8,15 @@ struct nlattr;
> struct nlmsghdr;
> struct nftnl_expr;
>
> +struct attr_policy {
> + size_t maxlen;
I'd make this an uint32_t since that is also whats
passed to expr_set().
> + if (expr->ops->attr_policy &&
> + type <= expr->ops->nftnl_max_attr &&
> + expr->ops->attr_policy[type].maxlen &&
> + expr->ops->attr_policy[type].maxlen < data_len)
> + return -1;
> +
I'd make this more strict, is there a reason to call ops->set
if type > ->nftnl_max_attr?
Something like:
!attr_policy -> return -1;
type > nftnl_max_attr -> return -1:
data_len > maxlen -> return -1.
We could also define a minlen to disallow setting
e.g. 1 byte of something that is internally an u32.
But I admit that this might break compatibility
or otherwise leak internals into the api.
next prev parent reply other threads:[~2023-12-13 20:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-13 19:02 [libnftnl RFC 1/2] expr: Repurpose struct expr_ops::max_attr field Phil Sutter
2023-12-13 19:02 ` [libnftnl RFC 2/2] expr: Introduce struct expr_ops::attr_policy Phil Sutter
2023-12-13 20:20 ` Florian Westphal [this message]
2023-12-13 21:51 ` Phil Sutter
2023-12-13 21:57 ` Florian Westphal
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=20231213202035.GA6601@breakpoint.cc \
--to=fw@strlen.de \
--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 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.