Re: nftables: parser conflict between tokens & symbols

[Florian Westphal <fw@strlen.de>]

Balazs Scheidler <balazs.scheidler@balabit.com> wrote:
> I've noticed that our set of keywords in nftables is pretty rich and
> this can cause conflicts in the grammar when a keyword is also used
> as a symbol.
> For instance, we do have a "redirect" expression and "redirect" as
> a word is also used as an ICMP message type.
> 
> # here is the redirect expression in action, which works:
> $ nft add rule tcp dport 80 redirect to 8080
> 
> # here's an ICMP rule that works
> $ nft add rule filter input icmp type echo-request accept
> 
> # here's an ICMP rule that should work, but it doesn't
> $ nft add rule filter input icmp type redirect accept
> 
> The root cause is that "redirect" is now recognized as a token, whereas the
> icmp type is expecting a STRING token.

While we're at it, there are other issues, f.e.:

ct label saddr
ct label == saddr

won't work since saddr is considered to be the SADDR token.
Similar issues for other places where we accept arbitrary symbol names.

I think the above might be fixable via

|       CT      ct_key  error
{
	yychar = STRING;
...

But of course that won't fix up all cases, e.g.
ct label == saddr would still not work since we encounter
the error (unexpected token) after a relational expression.

Does anyone have better ideas other than plastering parser with error
handlers...?