On Fri, Jul 31, 2020 at 02:36:33PM -0400, Eric Garver wrote: > 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 rescind this statement - user error on my part. Both versions break firewalld. It looks like the reply is in a different order than the input. So firewalld doesn't know where to find the rule handles. I'm trying to come up with a minimal reproducer.
