All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Westphal <fw@strlen.de>
To: Phil Sutter <phil@nwl.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 22:57:10 +0100	[thread overview]
Message-ID: <20231213215710.GA11700@breakpoint.cc> (raw)
In-Reply-To: <ZXonUyedK70ZMkFY@orbyte.nwl.cc>

Phil Sutter <phil@nwl.cc> wrote:
> > Something like:
> > 
> > !attr_policy -> return -1;
> 
> Which means I can't procrastinate writing the policies for all 40
> expressions. ;)

Oh, right.

> > type > nftnl_max_attr -> return -1:
> > data_len > maxlen -> return -1.
> 
> I wanted to make this an opt-in approach, so I'd rather go with
> maxlen && maxlen < data_len -> return -1.

Alright, it could be made more strict later
once all have been converted.

> > But I admit that this might break compatibility
> > or otherwise leak internals into the api.
> 
> It's not entirely straightforward, anyway. NFTNL_EXPR_IMM_CHAIN for
> instance accepts literally anything as long as it's a NUL-terminated
> string. I was unsure whether libnftnl should enforce
> NFT_CHAIN_MAXNAMELEN there or not.

Good point.  ATM libnftnl and nftables are more tightly coupled,
so I don't see why enforcing NFT_CHAIN_MAXNAMELEN would bite us
at some point.

We could also cap to 65528 which is what netlink would permit
(nla attr header plus playload).

      reply	other threads:[~2023-12-13 21:57 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
2023-12-13 21:51     ` Phil Sutter
2023-12-13 21:57       ` Florian Westphal [this message]

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=20231213215710.GA11700@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.