The 00-devmode-firewall.conf does not apply

from that page, I found this which is very intersting for me:

and after some turns to this one:

in particular this one:

in which this is crazy because force us to use infinitely long lines instead of multiple lines with all the craziness^2 when a patch is needed to be created.

Rules are separated with semicolons (;). All rules for a key must be on one line.

In fact the first consequence of this crazy syntax is immediate:

Rules can be commented out with hash tag (#) as first character. Commented rules
are simply ignored. For example:

IPv4.INPUT.RULES = #-p udp -m udp --dport 23 -j ACCEPT; -p udp -m udp --dport 24 -j ACCEPT

Will discard the first --dport 23 rule and use the second --dport 24 rule

Impose this restriction to the admins / users makes no sense expecially considering that

[General]

IPv4.INPUT.RULES = rule1
#IPv4.INPUT.RULES = rule2
IPv4.INPUT.RULES = rule3

can be easily parsed with

  • removes the commented lines
  • join all the remaining rules into the section per chain-name

Which means having a simple reg-expression pre-parser to make admin / users comfortable.

Secondly, also the rest of “The most notable exceptions” makes little sense for me because after all, it is just a matter to pass those instructions to iptables. Probably the connman should understand such a rules in some kind of ways. Therefore, I suspend my judgment.

Finally, we are on the point that I am caring about:

For this, for example following rules could be enabled to allow only DHCP and
DNS, into, e.g., /etc/connman/firewall.d/42-tethering-firewall.conf

In particular that files does not exist by default:

~]# ls -al /etc/connman/firewall.d/42-tethering-firewall.conf
ls: /etc/connman/firewall.d/42-tethering-firewall.conf: No such file or directory

creating or renaming one existing file would make that new file ignored. So, I decided to following the instructions exactly how they are proposed and surprinsingly (for me, now) it works even if I rename 42 with 12.

THE MISTAKE

The initial mistake was using -i tether into rule for [tethering], that’s all. Again, this hell could have been avoided in first place if a sanitizing regular expressions engine would elaborate the config files before being passed to connman. It would have removed -i tether because redundant and evidently inherited by the iptables rule used for testing, if found into [tethering] section, otherwise log an error and removed the rule (resilience) but not fail-over about the entire file (fragility).

4 Likes