Andy Kurth created VCL-996:

             Summary: Linux firewall subroutines do not sort rule numbers 
                 Key: VCL-996
             Project: VCL
          Issue Type: Bug
          Components: vcld (backend)
    Affects Versions: 2.4.2
            Reporter: Andy Kurth
            Assignee: Andy Kurth
             Fix For: 2.5

The {{enable_firewall_port}} and {{disable_firewall_port}} subroutines in retrieve the existing iptables rules.  The proper scope is then 
calculated.  They then construct a long command that deletes existing rules 
with _iptables -D_ then add rules back with _iptables -I_.  All of the 
individual iptables commands are chained by _&&_.  Example:
{code}iptables -D INPUT 4 && iptables -D INPUT 3 && iptables -D INPUT 2 && 
iptables -v -I INPUT 1 -p tcp...{code}

Existing rules are deleted by rule ID.  It is critical to delete them in order 
from highest to lowest otherwise the ID of subsequent rules will change.  For 
example, suppose you want to delete rules B, C and D which currently have IDs 
2, 3 and 4:
# A
# *{color:green}B{color}*
# *{color:green}C{color}*
# *{color:green}D{color}*
# E
# F

If the rules are deleted in ascending order (2,3,4), after the first deletion 
(B, ID=2) the IDs immediately become:
# A
# *{color:green}C{color}*
# *{color:green}D{color}*
# E
# F

Then rule 3 (currently D) is deleted, the IDs immediately become:
# A
# *{color:green}C{color}*
# E
# *{color:red}F{color}*

When the command finally deletes rule 4 it is deleting an unintended rule (F).

The code in is constructing the command with the IDs reverse sorted 
(good).  However, it's using Perl's default lexical sort instead of numeric 
(bad).  Because of this, rules are deleted in an order such as:

This causes various problems, including the possibility of locking the 
management node out.

This message was sent by Atlassian JIRA

Reply via email to