[jira] [Created] (VCL-996) Linux firewall subroutines do not sort rule numbers correctly

["Andy Kurth (JIRA)" <ji...@apache.org>]

Andy Kurth created VCL-996:
------------------------------

             Summary: Linux firewall subroutines do not sort rule numbers correctly
                 Key: VCL-996
                 URL: https://issues.apache.org/jira/browse/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 Linux.pm 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 Linux.pm 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:
3
2
11
10
1

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





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)