netfilter buglog - Feb 2006 - [Bug 446] New: parse_protocol lookup ordering issue

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=446

           Summary: parse_protocol lookup ordering issue
           Product: iptables
           Version: CVS (please indicate timestamp)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: iptables
        AssignedTo: laforge@netfilter.org
        ReportedBy: davidhi@cc.gatech.edu


Recently I migrated a set of systems to using LDAP for NSS and I noticed that
afterward the iptables script that was on each system (one I had not written)
took on the order of minutes to add each rule.  After stracing iptables, I found
it was trying to do LDAP lookups (but failing because the default rules were
DROP and LDAP wouldn't be opened until it got relatively far into the
script).
I couldn't understand why this was happening, until I noticed that it was
looking in /etc/protocols and not finding what it was looking for. 

After reading the code in the current repository, I noticed that parse_protocol
calls getprotobyname before it looks in the internal table, chain_protos.  It
was causing problems with '-p all' since 'all' is not likely to
be in the
/etc/protocols file causing NSS to fall through from files to ldap.  Only after
the ldap request had timed out did it use its own local table to process
'all.'

I'm not sure if this has been discussed before, so forgive me if this has
already been considered.  I realize looking in /etc/protocols first is probably
the desired behavior in certain cases, but this seems counterintuitive for the
wildcard 'all.'  Although I haven't tested it, it would also seem to
allow
someone to redefine 'all' in /etc/protocols.  Perhaps 'all'
should be removed or
the lookup order changed because it has the potential to really slow down the
process of adding a series of rules the way it works now.  Thanks.

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=446

           Summary: parse_protocol lookup ordering issue
           Product: iptables
           Version: CVS (please indicate timestamp)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: iptables
        AssignedTo: laforge@netfilter.org
        ReportedBy: davidhi@cc.gatech.edu


Recently I migrated a set of systems to using LDAP for NSS and I noticed that
afterward the iptables script that was on each system (one I had not written)
took on the order of minutes to add each rule.  After stracing iptables, I found
it was trying to do LDAP lookups (but failing because the default rules were
DROP and LDAP wouldn't be opened until it got relatively far into the
script).
I couldn't understand why this was happening, until I noticed that it was
looking in /etc/protocols and not finding what it was looking for. 

After reading the code in the current repository, I noticed that parse_protocol
calls getprotobyname before it looks in the internal table, chain_protos.  It
was causing problems with '-p all' since 'all' is not likely to
be in the
/etc/protocols file causing NSS to fall through from files to ldap.  Only after
the ldap request had timed out did it use its own local table to process
'all.'

I'm not sure if this has been discussed before, so forgive me if this has
already been considered.  I realize looking in /etc/protocols first is probably
the desired behavior in certain cases, but this seems counterintuitive for the
wildcard 'all.'  Although I haven't tested it, it would also seem to
allow
someone to redefine 'all' in /etc/protocols.  Perhaps 'all'
should be removed or
the lookup order changed because it has the potential to really slow down the
process of adding a series of rules the way it works now.  Thanks.

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.