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).