On Tue, Mar 19, 2019 at 12:06:24PM +0100, Pablo Neira Ayuso wrote:
> Hi Phil,
>
> On Mon, Mar 18, 2019 at 06:42:43PM +0100, Phil Sutter wrote:
> > On Fri, Mar 15, 2019 at 06:13:28PM +0100, Pablo Neira Ayuso wrote:
> [...]
> > > * Kernel would need to inconditionally build the OS:version string.
> >
> > Yes, exactly. nft_osf.c would return "OS:version:subtype:opt" and
> > nft_cmp.c will do the right thing if nft_cmp_expr->len is set to RHS
> > length.
>
> Problem are sets. They need a fixed size for the string, or we would
> need to adjust the size to the largest string in the set. In case of
> dynamic sets, this boils down to the maximum string length since we
> don't know what the length of future element would be.
I knew there's a rub! :)
> > > * We may need to ask users to break existing osf ruleset so they
> > > explicitly add the wildcard at the end, ie.
> > >
> > > osf name "Windows\*"
> > > osf name "Linux:4.\*"
> >
> > Not if cmp expr len is set correctly.
>
> cmp expr len is set correctly using the wildcard.
>
> I think we should aim to make this work fine with sets and maps. The
> wildcard cannot be used from there, where exact matches are needed. We
> should encourage users to use osf with sets and maps.
>
> > > then, in the future (if ever needed) add subtypes:
> > >
> > > osf subtype "Linux:2.4:cluster"
> >
> > IMHO this is still redundant: RHS contains <something>:<something>, user
> > wants to match on OS and version. RHS contains <sth>:<sth>:<sth>, user
> > wants to match on OS, version and subtype.
>
> This is not possible with dynamic sets, there the set may be empty so
> we do not know how many colons will be used :-)
Speaking of sets, it would be awesome if we could support something
like:
| osf genre { "Linux:2.4", "Windows" }
i.e., having elements with varying "granularity". Do you think that's
feasible? If so, how could we support that? Maybe using a concatenation
like:
| osf name . osf version { "Linux" . "2.4", "Windows" . "*" }
Cheers, Phil
