On Fri, Jul 31, 2020 at 07:19:06PM +0200, Pablo Neira Ayuso wrote: > On Fri, Jul 31, 2020 at 10:17:42AM -0400, Eric Garver wrote: > > On Fri, Jul 31, 2020 at 03:48:28PM +0200, Phil Sutter wrote: > > > On Fri, Jul 31, 2020 at 02:58:25PM +0200, Pablo Neira Ayuso wrote: > > > > On Fri, Jul 31, 2020 at 02:33:42PM +0200, Phil Sutter wrote: > [...] > > > I'm assuming scripts will work directly with the Python data structures > > > that are later passed to libnftables as JSON. If they want to change a > > > rule, e.g. add a statement, it is no use if other statements disappear > > > or new ones are added by the commit->retrieve action. > > > > > > Maybe Eric can shed some light on how Firewalld uses echo mode and > > > whether my concerns are relevant or not. > > > > How it stands today is exactly as you described above. firewalld relies > > on the output (--echo) being in the same order as the input. At the > > time, and I think still today, this was the _only_ way to reliably get > > the rule handles. It's mostly due to the fact that input != output. > > > > In the past we discussed allowing a user defined cookie/handle. This > > would allow applications to perform in a write only manner. They would > > not need to parse back the JSON since they already know the > > cookie/handle. IMO, this would be ideal for firewalld's use case. > > The question is: Is this patch breaking anything in firewalld? I tried v2 and v3. Neither break firewalld. I think this is because firewalld only relies on the input and output _order_ being identical. That is, the Nth input json element corresponds to the Nth output json element.