nftables: parser conflict between tokens & symbols

nftables: parser conflict between tokens & symbols

[Balazs Scheidler]

Hi,

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.

I have tried to solve this but the idea I had didn't work out, and I don't
really have more time now to fix it, but still thought this information
would be useful.

Cheers,
Bazsi

Re: nftables: parser conflict between tokens & symbols

[Florian Westphal]

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

Re: nftables: parser conflict between tokens & symbols

[Pablo Neira Ayuso]

On Mon, Jun 29, 2015 at 04:57:25PM +0200, Florian Westphal wrote:
> 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.

I don't think we're searching for such a flexibility in the grammar at
this stage.

Re: nftables: parser conflict between tokens & symbols

[Patrick McHardy]

Am 29. Juni 2015 20:09:29 MESZ, schrieb Pablo Neira Ayuso <pablo@netfilter.org>:
>On Mon, Jun 29, 2015 at 04:57:25PM +0200, Florian Westphal wrote:
>> 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.
>
>I don't think we're searching for such a flexibility in the grammar at
>this stage.

I know how to fix this once and for all by splitting the expression rules into non-const LHS and const RHS parts. This will unfortunately require to duplicate a lot of the productions.

I'll try to put something together during the next days.


-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: nftables: parser conflict between tokens & symbols

[Pablo Neira Ayuso]

On Fri, Jun 26, 2015 at 02:44:23PM +0200, Balazs Scheidler wrote:
> Hi,
> 
> 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.
> 
> I have tried to solve this but the idea I had didn't work out, and I don't
> really have more time now to fix it, but still thought this information
> would be useful.

The problem is known, the test infrastructure is catching this among
other existing problems. You can also file a bug to bugzilla if this
doesn't exist already so we can track this.