On Thu, Jan 12, 2023 at 12:06:55PM +0100, Pablo Neira Ayuso wrote: > On Thu, Jan 12, 2023 at 11:15:10AM +0100, Phil Sutter wrote: > > Bump? > > > > On Wed, Dec 21, 2022 at 03:22:21PM +0100, Phil Sutter wrote: > > > Allow for user space to provide an improved variant of the rule for > > > actual use. The variant in NFTA_RULE_EXPRESSIONS may provide maximum > > > compatibility for old user space tools (e.g. in outdated containers). > > > > > > The new attribute is also dumped back to user space, e.g. for comparison > > > against the compatible variant. > > > > > > While being at it, improve nft_rule_policy for NFTA_RULE_EXPRESSIONS. > > Could you split this in two patches? Separate the nft_rule_policy_change? Sure! > I still don't see how this is improving the situation for the scenario > you describe, if you could extend a bit on how you plan to use this > I'd appreciate. I can send you my WiP libnftnl and iptables patches if that helps. The approach this patch follows is pretty simple, though: The kernel will accept NFTA_RULE_ACTUAL_EXPR to override NFTA_RULE_EXPRESSIONS for use in the live ruleset. When fetching the ruleset, old user space will ignore NFTA_RULE_ACTUAL_EXPR, so new user space may submit a compatible variant of the rule in NFTA_RULE_EXPRESSIONS and a modern variant in NFTA_RULE_ACTUAL_EXPR. In iptables, when converting a rule from iptables_command_state into nftnl expressions, I insert all expressions into both NFTA_RULE_EXPRESSIONS and NFTA_RULE_ACTUAL_EXPR unless an extension does fancy stuff (e.g. was converted into native expressions). My test piece is limit match which had to be converted once (see commit 5de8dcf75941c for details): I add the native expressions to NFTA_RULE_ACTUAL_EXPR and create a compat "match" expression for NFTA_RULE_EXPRESSIONS only. The kernel will use the native expressions in the ruleset, dumps will contain the compat "match" expression instead. Cheers, Phil
