Re: libnftables extended API proposal (Was: Re: [nft PATCH] libnftables: Fix for multiple context instances)

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Dec 07, 2017 at 12:34:31PM +0100, Phil Sutter wrote:
> Hi Pablo,
> 
> On Thu, Dec 07, 2017 at 01:05:45AM +0100, Pablo Neira Ayuso wrote:
> > On Tue, Dec 05, 2017 at 02:43:17PM +0100, Phil Sutter wrote:
> [...]
> > > After tweaking the parser a bit, I can use it now to parse just a
> > > set_list_member_expr and use the struct expr it returns. This made it
> > > possible to create the desired struct cmd in above function without
> > > having to invoke the parser there.
> > > 
> > > Exercising this refining consequently should allow to reach arbitrary
> > > levels of granularity. For instance, one could stop at statement level,
> > > i.e. statements are created using a string representation. Or one could
> > > go down to expression level, and statements are created using one or two
> > > expressions (depending on whether it is relational or not). Of course
> > > this means the library will eventually become as complicated as the
> > > parser itself, not necessarily a good thing.
> > 
> > Yes, and we'll expose all internal representation details, that we
> > will need to maintain forever if we don't want to break backward.
> 
> Not necessarily. I had this in mind when declaring 'struct nft_table'
> instead of reusing 'struct table'. :)
> 
> The parser defines the grammar, the library would just follow it. So if
> a given internal change complies with the old grammar, it should comply
> with the library as well. Though this is quite theoretical, of course.
> 
> Let's take relational expressions as simple example: In bison, we define
> 'expr op rhs_expr'. An equivalent library function could be:
> 
> | struct nft_expr *nft_relational_new(struct nft_expr *,
> | 				      enum rel_ops,
> | 				      struct nft_expr *);

Then that means you would like to expose an API that allows you to
build the abstract syntax tree.

> What is allowed in rhs_expr may change internally without breaking ABI
> or the parser-defined language.
> 
> Can you think of a problematic situation? My view is probably a bit
> rose-coloured. ;)
>
> > > On the other hand, having an abstract representation for set elements is
> > > quite convenient - their string representations might differ (take e.g.
> > > "22" vs. "ssh") so strcmp() is not sufficient to compare them.
> > > 
> > > I hope this allows you to get an idea of how I imagine extended API
> > > although certainly details are missing here. What do you think about it?
> > > Are you fine with the general concept so we can discuss details or do
> > > you see a fundamental problem with it?
> > 
> > OK, my understanding is that you would like to operate with some
> > native library object representation.
> > 
> > Most objects (table, chain...) are easy to represent, as you
> > mentioned. Rules are the most complex ones internally, but you can
> > probably abstract a simplified representation that suits well for your
> > usecases, e.g expose them in an iptables like representation -
> > something like adding matches and actions - Obviously, this needs to
> > allow to take sets as input, eg.
> > 
> >         int meta_match_immediate(struct nft_rule *r, enum nft_meta_type, void *data);
> >         int meta_match_set(struct nft_rule *r, enum nft_meta_type, struct nft_set *set);
> > 
> > meta_match_immediate() adds a meta + cmp to the rule, to compare for
> > an immediate value. meta_match_set() adds meta + lookup.
> 
> Yes, that sounds good. I had something like this in mind:
> 
> | struct nft_stmt *nft_meta_match_immediate(enum nft_meta_type, void *data);
> | int nft_rule_append_stmt(struct nft_rule *r, struct nft_stmt *stmt);
> 
> The obvious problem is that at the time that meta match is created,
> there is no context information. So the second function would have to
> do that.
> 
> I am not sure if this kind of context evaluation works in any case. E.g.
> set elements are interpreted depending on the set they are added to. To
> my surprise, that wasn't really an issue - the parser interprets it as
> constant symbol, when evaluating the expression as part of adding it to
> the set it is resolved properly. This might not work in any case,
> though.

Not sure I follow, what's the problem with the "missing context"?

> > A list of use-cases, for the third party application, would be good to
> > have to design this API.
> 
> OK, I'll take firewalld as an example and come up with a number of
> use-cases which would help there.

Thanks, those use-cases would be very useful to design this.