firewall-cmd - rich-rule - permanent configuration

poma pomidorabelisima at gmail.com
Fri Jul 26 19:44:57 UTC 2013


On 26.07.2013 19:27, Jiri Popelka wrote:
> On 07/26/2013 05:44 PM, poma wrote:
>> # firewall-cmd --permanent --add-rich-rule='rule forward-port
>> port="2222" to-port="22" to-addr="192.168.100.2" protocol="tcp"
>> family="ipv4" source address="192.168.2.100"'
>> # firewall-cmd --permanent --list-rich-rules
>> rule family="ipv4" source address="192.168.2.100" forward-port
>> port="2222" protocol="tcp" to-port="22" to-addr="192.168.100.2"
> 
> The thing is that when firewalld adds a rich rule, this string rule is
> parsed and its representation is created in firewalld.
> Then when we want to list rich rules, the internal representation of
> rule is exported into string - but this string can be different from the
> one that was previously passed to --add-rich-rule. That's all right,
> because their meaning is the same, they just may have different order of
> elements.
> 
>> # firewall-cmd --permanent --remove-rich-rule='rule forward-port
>> port="2222" to-port="22" to-addr="192.168.100.2" protocol="tcp"
>> family="ipv4" source address="192.168.2.100"'
> 
> Problem is that when we remove or query rich-rule, in
> FirewallClientConfigZoneSettings() we compare this not yet
> parsed&exported string with already parsed&exported string and I said
> above the string may be different even their meaning is the same. And in
> this case the rule is not removed (or query fails).
> 
> I think in FirewallClientConfigZoneSettings() in
> {add|remove|query}RichRule() we need to first pass the input string
> through the parser&"exporter" before we can compare the string-only
> rich-rules.
> 
> -- 
> Jiri

OK, thanks for the further clarification.


poma




More information about the firewalld-devel mailing list