On 04.04, Alexander Holler wrote:
> Am 04.04.2015 um 13:55 schrieb Pablo Neira Ayuso:
> > On Sat, Apr 04, 2015 at 01:13:06PM +0200, Alexander Holler wrote:
> >> Context sensitive handling of "param-problem" and "redirect" is necessary
> >> to allow usage of them as token or as string for icmp types.
> > [...]
> >
> > I think we need some evaluation step at scanner level. This new
> > evaluation routine needs to understand the token semantics to set some
> > context information.
> >
> > "redirect" { return scanner_evaluate(ctx, REDIRECT); }
> >
> > We have to catch up more use cases such as sets and concatenations. I
> > started a patch here, a bit more generalized than this when you
> > reported this problem (we actually already knew about it).
> >
> > @Patrick, any better idea?
>
> Hmm. Looks ambitious.
>
> I've no idea if it's worse to spend the time to build a general solution
> instead of doing it like I did. It looks like you want to build a state
> machine inside that scanner_evaluate() which means you have to use it
> for every token, if I've understood your idea correctly.
>
> How many ambigious tokens do exist besides redirect and param-problem
> for which I've now added a "mini state machine"?
These cases keep coming up and we actually can't even know all cases
since many expressions use externally defined constants, f.i. services,
routing marks, realms etc, interface names and many more. We really
need a generic solution, at least in the mid term.
> Sorry, but I'm not actively following this project or the mailing lists,
> and thus have no real overview over existing problems. I've just fixed a
> problem I've encountered while switching some of my systems from
> iptables to nftables.
I'm not opposed to a short term fix until we have something generic.
However we used a different approach so far (for different cases though)
and I'd like to at least check whether something similar will work
in this case.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
