Destroy the temporary IP set in the cleanup function

Hello!

In the IP set capability tests, there is a race condition which might prevent the removal of the temporary IP set immediately after flushing the chain that uses this IP set: even though the rules which used the IP set were deleted, the IP set might still appear to be “in use by a kernel component.”

For instance, one can reproduce this race condition by the following:

1. Create a dummy IP set along with a chain and a rule using this IP set:

   # ipset -N dummy-set hash:ip family inet
   # iptables -w -N dummy-chain
   # iptables -w -A dummy-chain -m set --match-set dummy-set src -j ACCEPT

2. Flush the chain then immediately attempt to destroy the IP set:

   # iptables -w -F dummy-chain ; ipset -X dummy-set
   ipset v7.10: Set cannot be destroyed: it is in use by a kernel component

However, adding a sleep 0.1 before the ipset -X command will work.

If IP sets are used in the Shorewall configuration (e.g., in the blrules file), Shorewall will test for the IP set capability when starting. However, since the IP sets are destroyed by these test functions right after the corresponding chains are flushed (see lines 4852 or 4881 of Shorewall/Perl/Shorewall/Config.pm), the race condition may happen (in fact, it always happened in the tests I ran), and the temporary IP set will still be there even after Shorewall has started, as can be verified with ipset -L:

# ipset -L
Name: fooX1312
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 200
References: 0
Number of entries: 0
Members:

In case this happens, the proposed patch here is to add an extra call to ipset -X in the cleanup_iptables() function, just to ensure that the temporary IP set is indeed destroyed when the compiler exits.

From what I could test on my setup, this patch solved the issue, and no temporary fooX... IP set remained after starting Shorewall.

Thanks!