On 6/26/19 2:59 PM, Arturo Borrero Gonzalez wrote: > On 6/26/19 2:28 PM, Thomas Lamprecht wrote: >> Hmm, but that's a grave issue which may just render the firewall void >> for _any_ intermediate chain and produces segmentation faults errors. >> > The issue you found is not a general-case issue. > The segfault is only produced apparently if you: > > * define a custom chain > * flush all rules of that custom chain (not required, because the chain was > just > created) > * add a rule to that custom chain > > all in the same batch. > > I may understand that this is important for some scripts or robots making use > of > the iptables interface in that particular way, but is not the general case of > how people define and add rules to custom chain/ruleset. > Because of this, I think we should lower the severity of this bug.
I see this exactly the other way, this is the normal use case for iptables-restore, i.e.: * iptables-save before shutdown * iptables-restore after boot And in such an use all your points always happen in one batch. Also, all my servers do it that way and I do not think that manual, rule-by-rule, iptables editing is the norm or general case, like you're trying to suggest. I only add new stuff this way, and that only quite seldom. If I had not tried this before quite a few of my servers would have been without any FW rule, no protection, no NAT masquerading for LANs, this would have real and bad implications... Because of this, I think the bug importance downgrade now should not be done, this is IMO still grave. I mean I and we as downstream distro with a few 100k users now know it and can work around it, but I guess that this may hit quite some Debian users which update to Buster without knowing that they would even need working around this.
