Re: Unable to create a chain called "trace"

[Phil Sutter <phil@nwl.cc>]

Hi,

On Fri, Feb 12, 2021 at 06:09:21PM +0100, Pablo Neira Ayuso wrote:
> On Fri, Feb 12, 2021 at 01:20:07PM +0100, Florian Westphal wrote:
> > Phil Sutter <phil@nwl.cc> wrote:
> > > I didn't find a better way to conditionally parse two following args as
> > > strings instead of just a single one. Basically I miss an explicit end
> > > condition from which to call BEGIN(0).
> > 
> > Yes, thats part of the problem.
> > 
> > > > Seems we need allow "{" for "*" and then count the {} nests so
> > > > we can pop off a scanner state stack once we make it back to the
> > > > same } level that we had at the last state switch.
> > > 
> > > What is the problem?
> > 
> > Detect when we need to exit the current start condition.
> > 
> > We may not even be able to do BEGIN(0) if we have multiple, nested
> > start conditionals. flex supports start condition stacks, but that
> > still leaves the exit/closure issue.
> > 
> > Example:
> > 
> > table chain {
> >  chain bla {  /* should start to recognize rules, but
> > 		 we did not see 'rule' keyword */
> > 	ip saddr { ... } /* can't exit rule start condition on } ... */
> > 	ip daddr { ... }
> >  }  /* should disable rule keywords again */
> > 
> >  chain dynamic { /* so 'dynamic' is a string here ... */
> >  }
> > }
> > 
> > I don't see a solution, perhaps add dummy bison rule(s)
> > to explicitly signal closure of e.g. a rule context?
> 
> It should also be possible to add an explicit rule to allow for
> keywords to be used as table/chain/... identifier.

Which means we have to collect and maintain a list of all known keywords
which is at least error-prone.

> It should be possible to add a test script in the infrastructure to
> create table/chain/... using keywords, to make sure this does not
> break.

You mean something that auto-generates the list of keywords to try?

> It's not nice, but it's simple and we don't mingle with flex.
> 
> I have attached an example patchset (see patch 2/2), it's incomplete.
> I could also have a look at adding such regression test.

Ah, I tried that path but always ended with shift/reduce conflicts. They
appear when replacing DYNAMIC with e.g. TABLE, CHAIN or RULE in your
patch. Of course we may declare that none of those is a sane name for a
table, but I wonder if we'll discover less obvious cases later.

Cheers, Phil