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.
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.
