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: [libnftnl PATCH] utils: Add helpers for interface name wildcards
Date: Tue, 22 Jul 2025 15:43:49 +0200 [thread overview]
Message-ID: <aH-VlSW8TxjMNrHN@orbyte.nwl.cc> (raw)
In-Reply-To: <aH77oyMqwmO3x3V9@calendula>
On Tue, Jul 22, 2025 at 04:46:59AM +0200, Pablo Neira Ayuso wrote:
> Hi Phil,
>
> On Wed, Jul 16, 2025 at 03:22:06PM +0200, Phil Sutter wrote:
> > Support simple (suffix) wildcards in NFTNL_CHAIN_DEV(ICES) and
> > NFTA_FLOWTABLE_HOOK_DEVS identified by non-NUL-terminated strings. Add
> > helpers converting to and from the human-readable asterisk-suffix
> > notation.
>
> We spent some time discussing scenarios where host and container could
> use different userspace versions (older vs. newer).
>
> In this case, newer version will send a string without the trailing
> null character to the kernel. Then, the older version will just
> _crash_ when parsing the netlink message from the kernel because it
> expects a string that is nul-terminated (and we cannot fix an old
> libnftnl library... it is not possible to fix the past, but it is
> better if you can just deal with it).
Yes, this sucks. In a quick test, my host's nft would display "foo" for
a device spec of "foo*", but I believe this largely depends upon string
lengths, alignment and function-local buffer initial contents.
> I suggest you maybe pass the * at the end of the string to the kernel
> so nft_netdev_hook_alloc() can just handle this special case and we
> always have a nul-terminated string? There is ifnamelen which does in
> the kernel what you need to compare the strings, while ifname can
> still contain the *.
We can't distinguish this from real device names ending with asterisk,
though (Yes, no sane person would create those but since it's possible
there must be at least one doing it).
We could use a forbidden character to signal the wildcard instead.
Looking at dev_valid_name(), we may choose between '/', ':' and any of
the characters recognized by isspace(). I'd suggest to use something
fancy like '\v' (vertical tab) to lower the risk of hiding a user space
bug appending something the user may have inserted.
> Worth a fix? Not much time ahead, but we are still in -rc7.
Fine with me if we find a solution that works!
Cheers, Phil
next prev parent reply other threads:[~2025-07-22 13:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-16 13:22 [libnftnl PATCH] utils: Add helpers for interface name wildcards Phil Sutter
2025-07-22 2:46 ` Pablo Neira Ayuso
2025-07-22 13:43 ` Phil Sutter [this message]
2025-07-22 23:33 ` Pablo Neira Ayuso
2025-07-23 0:07 ` Pablo Neira Ayuso
2025-07-23 11:49 ` 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=aH-VlSW8TxjMNrHN@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 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).