On Monday 2009-08-10 08:58, Patrick McHardy wrote: >> >> The second and more interesting point is that this would also introduce >> a timeframe where packets could slip through while these exchanges >> between kernel and userspace are happening. Why does setting the policy >> to DROP not solve this problem? > >This is not correct, the replacement is atomic. (Elaborating on this.) The _replacement_ itself is indeed atomic, the issue arises when a table is in place that allows something that is later restricted again by a new table update. 1. iptables -A INPUT -p esp -j ACCEPT 2. echo 'Possibly open from here on...' 3. iptables -P FORWARD DROP 4. echo 'Now closed again' Now if you have a large ruleset, and RT preemption, or lots of CPUs, or an overly busy system, etc., it may take "longer than usual" until step 3 is in effect. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
