summaryrefslogtreecommitdiffstats
path: root/libiptc
Commit message (Collapse)AuthorAgeFilesLines
* libiptc: fix retry path in TC_INITMiguel GAIO2012-04-191-1/+1
| | | | | | | | | | | There is an issue on TC_INIT retry path: In error case, TC_FREE is called and close sockfd. The retry does not reopen then always fail. The proposing patch reopens sockfd in retry patch. Signed-off-by: Miguel GAIO <miguel.gaio@efixo.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* src: mark newly opened fds as FD_CLOEXEC (close on exec)Maciej Żenczykowski2012-03-231-0/+8
| | | | | | | | | | | | | | | | | | By default, Unix-like systems leak file descriptors after fork/exec call. I think this seem to result in SELinux spotting a strange AVC log messages according to what I can find on the web. Fedora 18 iptables source includes this change. Maciej says: "iptables does potentially fork/exec modprobe to load modules. That can cause a selinux 'domain'/'role'/whatever-it-is-called crossing. You can do automated inspection of what gets carried across such privilege changes and any unexpected open file descriptors flag problems, patches like this cut down on the noise." Signed-off-by: Maciej enczykowski <maze@google.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* iptables: missing free() in function delete_entry()Franz Flasch2012-03-121-1/+3
| | | | | | | | Fixed a memory leak in the dry run path of function delete_entry(). Signed-off-by: Franz Flasch <franz.flasch@frequentis.com> Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* iptables: missing free() in function cache_add_entry()Franz Flasch2012-03-121-0/+1
| | | | | | | | Fixed a memory leak in the error path of function cache_add_entry(). Signed-off-by: Franz Flasch <franz.flasch@frequentis.com> Signed-off-by: Christian Engelmayer <christian.engelmayer@frequentis.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
* Revert "libiptc: Returns the position the entry was inserted"Pablo Neira Ayuso2012-03-011-3/+2
| | | | | | | | | This reverts commit d65702c5c5bbab0ef12298386fa4098c72584e6c. This is breaking my iptables scripts: iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables: Incompatible with this kernel.
* libiptc: Returns the position the entry was insertedJonh Wendell2012-02-291-2/+3
| | | | Jan Engelhardt showed no objections to this patch.
* Merge branch 'stable'Jan Engelhardt2011-12-184-83/+69
|\
| * libiptc: use a family-invariant xtc_ops struct for code reductionJan Engelhardt2011-09-114-2/+16
| | | | | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
| * src: resolve old macro names that are indirectionsJan Engelhardt2011-09-112-31/+31
| | | | | | | | | | | | | | | | | | | | | | Command used: git grep -f <(pcregrep -hior '(?<=#define\s)IP6?(T_\w+)(?=\s+X\1)' include/) and then fix all occurrences. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
| * libiptc: combine common types: _handleJan Engelhardt2011-09-113-13/+6
| | | | | | | | | | | | | | No real API/ABI change incurred, since the definition of the structs' types is not visible anyhow. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
| * libiptc: replace ipt_chainlabel by xt_chainlabelJan Engelhardt2011-09-112-2/+2
| | | | | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
| * libiptc: remove unused HOOK_DROPPING thingJan Engelhardt2011-09-112-15/+0
| | | | | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
| * libiptc: resolve compile failureJan Engelhardt2011-09-111-20/+14
| | | | | | | | | | | | | | | | | | | | | | CC libip4tc.lo In file included from libip4tc.c:118:0: libiptc.c:70:8: error: redefinition of "struct xt_error_target" ../include/linux/netfilter/x_tables.h:69:8: note: originally defined here Remove libiptc's duplicate definition and substitute names. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* | libiptc: provide separate pkgconfig filesJan Engelhardt2011-12-185-6/+24
|/ | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* iptables: Coverity: DEADCODEJiri Popelka2011-06-221-3/+1
| | | | | | | | | | | | | | | | libiptc.c:407: dead_error_condition: On this path, the condition "res > 0" cannot be false. libiptc.c:396: at_least: After this line, the value of "res" is at least 1. libiptc.c:393: equality_cond: Condition "res == 0" is evaluated as false. libiptc.c:396: new_values: Noticing condition "res < 0". libiptc.c:425: new_values: Noticing condition "res < 0". libiptc.c:407: new_values: Noticing condition "res > 0". libiptc.c:435: dead_error_line: Execution cannot reach this statement "return list_pos;". Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* build: re-add missing CPPFLAGS for libiptcJan Engelhardt2011-06-081-0/+3
| | | | | | | | | | These got lost on commit v1.4.11-12-g5c8f5b6. Note: When /usr/include/libiptc/libiptc.h exists, this error is masked away :-/ (IMO, #include-with-quotes "foo.h" should not search system dirs...) Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* src: move all libiptc pieces into its directoryJan Engelhardt2011-06-073-0/+25
| | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* build: remove dead code partsJan Engelhardt2011-05-301-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | gcc-4.6 has a new warning, -Wunused-but-set-variable, which flags no-op code. CC libiptc/libip4tc.lo In file included from libiptc/libip4tc.c:118:0: libiptc/libiptc.c: In function "iptcc_chain_index_delete_chain": libiptc/libiptc.c:611:32: warning: variable "index_ptr2" set but not used libiptc/libiptc.c: In function "alloc_handle": libiptc/libiptc.c:1282:9: warning: variable "len" set but not used CC libiptc/libip6tc.lo In file included from libiptc/libip6tc.c:113:0: libiptc/libiptc.c: In function "iptcc_chain_index_delete_chain": libiptc/libiptc.c:611:32: warning: variable "index_ptr2" set but not used libiptc/libiptc.c: In function "alloc_handle": libiptc/libiptc.c:1282:9: warning: variable "len" set but not used CC xtables_multi-iptables-xml.o iptables-xml.c: In function "do_rule_part": iptables-xml.c:376:8: warning: variable "thisChain" set but not used CC xtables_multi-ip6tables.o ip6tables.c: In function "print_firewall": ip6tables.c:552:10: warning: variable "flags" set but not used Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* src: replace old IP*T_ALIGN macrosJan Engelhardt2011-05-122-4/+4
| | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* iptables: add -C to check for existing rulesStefan Tomanek2011-03-083-6/+26
| | | | | | | | | | | | | | | | | It is often useful to check whether a specific rule is already present in a chain without actually modifying the iptables config. Services like fail2ban usually employ techniques like grepping through the output of "iptables -L" which is quite error prone. This patch adds a new operation -C to the iptables command which mostly works like -D; it can detect and indicate the existence of the specified rule by modifying the exit code. The new operation TC_CHECK_ENTRY uses the same code as the -D operation, whose functions got a dry-run parameter appended. Signed-off-by: Stefan Tomanek <stefan.tomanek@wertarbyte.de> Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* src: use C99/POSIX typesJan Engelhardt2011-01-081-2/+2
| | | | | | "u_int" was a non-standardized extension predating C99 on some platforms. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* libip4tc: Add static qualifier to dump_entry()Dmitry V. Levin2010-02-181-2/+2
| | | | | | | | | Change dump_entry() signature defined in libip4tc.c to match prototype declared in libiptc.c and another static dump_entry() function defined in libip6tc.c. This function is not a part of the public libiptc API. Signed-off-by: Dmitry V. Levin <ldv@altlinux.org> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix wrong maptype of base chain counters on restoreJan Engelhardt2009-10-291-1/+1
| | | | | | | | | | | | | | | When a ruleset that does not reset any chain policies/counters, such as *filter COMMIT is sourced by iptables-restore, the previous policy and counters (i.e. the ones read from the kernel) are reused. The counter skew offsetting is wrong however, causing the read value to be readded to the kernel value. This manifests itself in practice by the counter value almost doubling everytime iptables-restore is called. Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* libiptc: avoid strict-aliasing warningsJan Engelhardt2009-10-253-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | In file included from libiptc/libip4tc.c:117:0: libiptc/libiptc.c: In function ‘__iptcc_p_del_policy’: libiptc/libiptc.c:826:4: warning: dereferencing type-punned pointer will break strict-aliasing rules libiptc/libiptc.c: In function ‘iptc_get_target’: libiptc/libiptc.c:1650:4: warning: dereferencing type-punned pointer will break strict-aliasing rules libiptc/libip4tc.c: In function ‘dump_entry’: libiptc/libip4tc.c:157:3: warning: dereferencing type-punned pointer will break strict-aliasing rules CC libiptc/libip6tc.lo In file included from libiptc/libip6tc.c:112:0: libiptc/libiptc.c: In function ‘__iptcc_p_del_policy’: libiptc/libiptc.c:826:4: warning: dereferencing type-punned pointer will break strict-aliasing rules libiptc/libiptc.c: In function ‘ip6tc_get_target’: libiptc/libiptc.c:1650:4: warning: dereferencing type-punned pointer will break strict-aliasing rules libiptc/libip6tc.c: In function ‘dump_entry’: libiptc/libip6tc.c:188:3: warning: dereferencing type-punned pointer will break strict-aliasing rules Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* libiptc: remove unused functionsJan Engelhardt2009-10-251-39/+0
| | | | | | | | | | | | | Fix the two warnings in libiptc.c: CC libiptc/libip4tc.lo libiptc/libiptc.c:1570:1: warning: ‘iptc_num_rules’ defined but not used libiptc/libiptc.c:1586:1: warning: ‘iptc_get_rule’ defined but not used CC libiptc/libip6tc.lo libiptc/libiptc.c:1570:1: warning: ‘ip6tc_num_rules’ defined but not used libiptc/libiptc.c:1586:1: warning: ‘ip6tc_get_rule’ defined but not used Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
* libiptc: give credits to my selfJesper Dangaard Brouer2009-03-231-0/+5
| | | | | | | | Add notes about my scalability work on the library libiptc. This should make in more obvious who to complain to. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix whitespaces and typosJesper Dangaard Brouer2009-03-231-41/+41
| | | | | | | Cleanup whitespaces while going through the code. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix chain rename bug in libiptcJesper Dangaard Brouer2009-03-231-1/+8
| | | | | | | | | Chain renaming (TC_RENAME_CHAIN) can result in an unsorted chain list. That breaks the requirement of the binary search done in iptcc_bsearch_chain_index(). Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: avoid compile warnings for iptc_insert_chainChristoph Paasch2009-03-231-1/+1
| | | | | | | | iptc_insert_chain is too big to get inlined and so it generates a warning while compiling. Signed-off-by: Christoph Paasch <christoph.paasch@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: guard chain index allocation for different malloc implementationsJan Engelhardt2008-11-261-1/+1
| | | | | | | | Some libc implementations such as µClibc return NULL on malloc(0). They are free to do that per C standard. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signeed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: make sockfd a per-handle thingJan Engelhardt2008-11-101-24/+14
| | | | | | | Get away from this singleton. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: use hex output for hookmaskJan Engelhardt2008-11-101-2/+2
| | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove unused iptc_get_raw_socket and iptc_check_packetJan Engelhardt2008-11-103-26/+0
| | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove indirectionsJan Engelhardt2008-11-101-116/+113
| | | | | Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove typedef indirectionJan Engelhardt2008-11-103-73/+73
| | | | | | | | | | | Don't you hate it when iptc_handle_t *x actually is a double-indirection struct iptc_handle **? This also shows the broken constness model, since "const iptc_handle_t x" = "iptc_handle_t const x" = "struct iptc_handle *const x", which is like no const at all. Lots of things to do then. Signed-off-by: Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: remove old fixmeJesper Dangaard Brouer2008-09-241-2/+0
| | | | | | | Chains _are_ sorted, binary search depend on it! Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: fix scalability performance issue during initial ruleset parsingJesper Dangaard Brouer2008-07-031-11/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Finding jump chains is slow O(Chain*Rules). The problem: is that the chain list is searched lineary for each rule with a jump target. The problem lies in the "second pass" (of function parse_table) where the userchain jump targets are found. For each rule "R" with a IPTCC_R_JUMP target, function iptcc_find_chain_by_offset() searches through the chains "C" in the chain list (worst-case hitting the last one). The solution: in this patch is to speed up iptcc_find_chain_by_offset() by using binary search. Reducing complexity from O(C) to O(log C). Implementation: Its possible to use the same bsearch algorithm and data structure (chain_index), as used for chain name searching. How is that possible: One has to realize that the chains are both sorted by name and offsets, this is because the chains are already sorted in the ruleset from the kernel. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: minor bugfixJesper Dangaard Brouer2008-07-031-1/+2
| | | | | | | | Minor bugfix, an extra check is needed if the tail element is a builtin chain, as builtin chains are not sorted. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk> Signed-off-by: Patrick McHardy <kaber@trash.net>
* libiptc: move variable definitions to head of functionPatrick McHardy2008-06-071-2/+4
| | | | Signed-off-by: Patrick McHardy <kaber@trash.net>
* Use s6_addr32 to access bits in int6_addr instead of incompatible nameYasuyuki Kozakai2008-06-041-1/+1
| | | | | | | Spotted by Khem Raj <raj.khem@gmail.com> Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net>
* Remove old functions, constantsJan Engelhardt2008-04-151-1/+2
|
* Combine IP{,6}T_LIB_DIR into XTABLES_LIBDIRJan Engelhardt2008-04-131-4/+0
|
* Fix all remaining warnings (missing declarations, missing prototypes)Jan Engelhardt2008-04-131-5/+4
|
* Fix -Wshadow warnings and clean up xt_sctp.hJan Engelhardt2008-04-061-27/+22
| | | | | Note: xt_sctp.h is still not merged upstream in the kernel as of this commit. But a refactoring was really needed.
* Retry ruleset dump when kernel returns EAGAIN.Patrick McHardy2008-04-021-1/+4
| | | | Bugzilla #104
* Remove obsolete filePatrick McHardy2008-01-201-24/+0
|
* Solving scalability issue: for chain list "name" searching.Jesper Dangaard Brouer2008-01-151-4/+414
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Solving scalability issue: for chain list "name" searching. Functions: iptcc_find_label(), iptc_is_chain(). Testing if a chain exist, requires a linearly walk of linked list with chain-names (doing a strcmp(3) in each step). Giving a worst-case runtime of O(n) where n is the number of chains. Why is this important to fix?! If only called once, this should not be a big concern, even-though the string compares are expensive. The performance issue arise with many chains for example; when using "iptables-restore", or when listing all "iptables -nL" rules, or when using CPAN IPTables::libiptc. Having 50k chains, the rule listing, with the command: "./iptables -nL > /dev/null", Without patch it takes approximately 5 minutes, With the patch it takes 0.5 seconds. Listing without patch: real 4m49.426s user 4m37.993s sys 0m0.280s Listing with patch: real 0m0.558s user 0m0.484s sys 0m0.064s How is it solved?! The issue is solved introducing a new data structure, that allow us to do binary search of chain names. Thus, reducing the worst-case runtime to O(log n). Being more specific: The new data structure is called "chain index", which is an array with pointers into the chain list, with CHAIN_INDEX_BUCKET_LEN spacing. This facilitates the ability to speedup chain list searching, by find a more optimal starting points when searching the linked list. The runtime complexity is actually also affected by this "bucket" size concept. Thus, O(log(n/k) + k) where k is CHAIN_INDEX_BUCKET_LEN. A nice property of the chain index, is that the "bucket" list length is max CHAIN_INDEX_BUCKET_LEN (when just build, inserts will change this). Oppose to hashing, where the "bucket" list length can vary a lot. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* Introduce a counter for number of user defined chains.Jesper Dangaard Brouer2008-01-151-1/+7
| | | | | | Introduce a counter for number of user defined chains. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* Inline functions iptcc_is_builtin() and set_changed().Jesper Dangaard Brouer2008-01-151-2/+2
| | | | | | | The two functions are obvious candidates for inlining. Using gprof(1) shows that they actually affects performance. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
* More safe chain sorting, improving r7098Jesper Dangaard Brouer2007-12-121-1/+17
| | | | | | | | | | | | | | | | | This patch is an improvment of r7098 (made by me). Assuring compatibility between 1.4.0 and older versions, regarding chain sorting. Chains from kernel are already sorted, as they are inserted sorted. But there exists an issue when shifting to 1.4.0 from an older version, as old versions allow last created chain to be unsorted. This unsorted chain would survive in 1.4.0, as chains are now only sorted on creation. This patch verifies that chains are sorted, if not it fixes the sorting. Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
generated by cgit v1.2.3 (git 2.25.0) at 2024-11-01 01:22:57 +0000