Re: [nf_tables] suggestion: system-wide sets

[Patrick McHardy <kaber@trash.net>]

On Thu, Feb 27, 2014 at 03:46:12PM +0100, Arturo Borrero Gonzalez wrote:
> On 27 February 2014 15:02, Patrick McHardy <kaber@trash.net> wrote:
> > On Thu, Feb 27, 2014 at 01:15:36PM +0100, Arturo Borrero Gonzalez wrote:
> >> Hi there!
> >>
> >> I can't remember this subject being discussed in the near past.
> >>
> >> Why not using system-wide sets? Or at least, family-wide sets?
> >>
> >> >From the user point of view, I think is very interesting to define
> >> sets that can be used in rules all across the ruleset, same set in
> >> different tables and families.
> >
> > Yeah, I agree. I think family wide sets and global (AF_UNSPEC) sets should
> > bet quite easy to add. However there's the question how to expose them
> > in the nft list table output. The idea is to be able to recreate the
> > current ruleset, including sets and elements, by parsing the output of
> > nft list table. If we don't include sets, the user will have to seperately
> > save and restore them. OTOH if we simply include global and AF-specific
> > sets, they will be restored once for each table and this will fail on
> > the second table.
> >
> > Any other ideas?
> 
> idea 1:
> 
> print global sets when listing every time a table is listed.
> 
> To backup the ruleset, the user must iterate over the list of
> tables/AF (nft list table $AF $TABLE), so the global sets get printed
> several times.
> 
> when restoring, try to add the global set to the kernel.
> If the set already exist, return EEXIST from the kernel, and let nft
> ignore that if operating with 'nft -f'.

Yeah, that might work. However, how do we know that this it contains the
correct elements?

> idea 2:
> 
> add `nft list ruleset', which prints all tables in all AF, including
> global sets.
> Global sets are only printed in this 'ruleset' view.
> 
> Still, the ignore EEXIST errors from the kernel for globals sets.

Also something worth considering. I'm not sure about this yet, let me
think about this a bit.

> >> Being family-wide is what ipset does, and I'm sure is what most people
> >> will expect.
> >>
> >> On the other hand, I understand this would be a major change at this point.
> >
> > Should be fine. I'm thinking of keeping the table specific sets and also
> > having per AF and AF_UNSPEC sets. For maps we should restrict this feature
> > to data maps since verdicts may need a table context.
> 
> I agree.