Re: [libnftnl PATCH] utils: Add helpers for interface name wildcards

[Phil Sutter <phil@nwl.cc>]

On Wed, Jul 23, 2025 at 01:33:40AM +0200, Pablo Neira Ayuso wrote:
> Hi Phil,
> 
> On Tue, Jul 22, 2025 at 03:43:49PM +0200, Phil Sutter wrote:
> > 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 see.
> 
> > > 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).
> 
> This is hard by looking only at the Value of the TLV.
> 
> > 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.
> 
> Let's look at this problem from a different side.
> 
> I'd suggest you add new netlink attribute NFTA_DEVICE_WILDCARD to
> address this, ie.
> 
> enum nft_devices_attributes {
>         NFTA_DEVICE_UNSPEC,
>         NFTA_DEVICE_NAME,
> +       NFTA_DEVICE_WILDCARD,
>         __NFTA_DEVICE_MAX
> };
> 
> And use this new attribute for wildcard interface matching.
> 
> > > Worth a fix? Not much time ahead, but we are still in -rc7.
> > 
> > Fine with me if we find a solution that works!
> 
> This approach allows for newer nftables version to fail with old
> kernels, ie. user requests to match on wildcard device and kernel does
> not support it. I think it is convenient to bail out if user requests
> an unsupported kernel feature.

Yes, this seems reasonable. Right now old kernels would search for the
prefix as full interface name which is sane but may lead to unexpected
results: E.g. on a system with eth1, eth10 and eth11, the kernel would
find a device matching "eth1*" and users had to check 'list hooks' to
see what really happened.

> As for matching on an interface whose name is really eth*, nftables
> userspace already allows for ifname eth\* to represent this, ie.
> 
>         iifname eth*   <-- wildcard matching (99% use-case)
>         iifname eth\*  <-- to match on exotic (still valid) device name (1% use-case)
> 
> See special for '\\' in expr_evaluate_string() for handling this
> special case.
> 
> It would be good if evaluate_device_expr() already provides an easy
> way for the mnl backend to distinguish between wildcard matching or
> exact device name matching.

Looks like I opened a new can by mentioning interfaces named "eth*", as
my proposed user space implementation doesn't support them it seems.

Changing my code to use a new attribute NFTA_DEVICE_WILDCARD should be
easy, but I'll look into proper evaluate integration.

Thanks, Phil