Hi, On Thu, Mar 14, 2019 at 02:58:40PM +0100, Pablo Neira Ayuso wrote: > Hi, > > On Thu, Mar 14, 2019 at 12:14:23PM +0100, Fernando Fernandez Mancera wrote: > > Hi, > > > > I have been thinking more about this today. I don't know how access to > > the right-hand-side string from the kernel if it is possible. Sorry if > > the question is very dumb, but I may lack experience with the nft > > registers and RHS data of an expression. > > I think you can hide flags from json, which is what Phil suggests, I > mean, just infer version flags from the syntax, ie. if > "genre::version" is used, then set of the version flag. > > I think Phil is not suggesting kernel changes. Actually I'm still in the process of understanding how all this works. What I got so far is (correct me if I'm wrong): osf expr does the fingerprinting and returns a string which relational expr compares to right-hand side. This new version flag defines whether osf expr adds the version to returned string or not. Assuming the above is correct, my suggestion of making the flag option implicit does not quite hold, at least not without painful postprocessing of relational statement in userspace. Right now this all seems to me like enabling multiple comparisons within a single relational, i.e. one for genre and the other for version. Nftables doesn't quite do such things. E.g. matching on two TCP header fields requires two relationals, e.g. 'tcp dport 22 tcp sport > 1024'. Internally then, these two statements may be combined into a single payload match if suitable. Applying the same logic to osf expression, we would implement 'osf name foo osf version 3.141' and add 'osf_try_merge()' routine to 'rule_postprocess()' which tries to combine the two statements. Obviously, this is quite a bit of extra work, not sure if feasible. Cheers, Phil
