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? And if so, what is it breaking? I don't find a good reason why maintaining two different codepaths for --json --echo in the codebase is needed. Thanks.
