[nftables] bug: rejects single-element intervals as supposedly empty

[nftables] bug: rejects single-element intervals as supposedly empty

[Florian Zumbiehl]

Hi,

I stumbled upon this bug in the Debian buster backports version of nftables
(0.9.2-1~bpo10+1), the git commit log doesn't look like this has been fixed
since, so here it is:

| # nft add rule foo bar udp dport 1-1
| Error: Range has zero or negative size
| add rule foo bar udp dport 1-1
|                            ^^^

Regards, Florian

Re: [nftables] bug: rejects single-element intervals as supposedly empty

[Florian Westphal]

Florian Zumbiehl <florz@florz.de> wrote:
> I stumbled upon this bug in the Debian buster backports version of nftables
> (0.9.2-1~bpo10+1), the git commit log doesn't look like this has been fixed
> since, so here it is:
> 
> | # nft add rule foo bar udp dport 1-1
> | Error: Range has zero or negative size
> | add rule foo bar udp dport 1-1

I'd guess this is intentional and nft assumes user
meant something else such as 1-2 or 1-11.

We could autotranslate this to "dport 1" but I'm not sure its right.

Re: [nftables] bug: rejects single-element intervals as supposedly empty

[Florian Zumbiehl]

Hi,

> > | # nft add rule foo bar udp dport 1-1
> > | Error: Range has zero or negative size
> > | add rule foo bar udp dport 1-1
> 
> I'd guess this is intentional and nft assumes user
> meant something else such as 1-2 or 1-11.

Well, I would hope it is not intentional to claim that a one-element set
has zero or fewer elements!?

> We could autotranslate this to "dport 1" but I'm not sure its right.

Well, I don't know enough about the internals to know whether "translation"
is the right thing to do, but I would think the intended meaning (i.e.,
match port 1) is obvious, so that is what should happen?

Second-guessing the user on input that would seem obviously valid and
well-defined based on the documentation certainly doesn't seem like a good
idea to me. Just because there is a possibly more efficient way to encode
the same rule doesn't seem like a good reason to reject this encoding, as
that just complicates everything, and especially any code interfacing with
this, as you then have to special-case all those cases instead of just
generating a universal format that can represent all possible cases.

Also, nft accepts 1.2.3.4/32 just fine, or 1.2.3.0-1.2.3.255, which both
could be encoded more efficiently as well.

Regards, Florian