Anyone know if the iptables-restore command operates atomically? I want to make sure that the entirety of in-kernel iptables are switched over to those specified in the input to iptables-restore, all at once, with no intervening emptiness, incompleteness, or mixing with prior table. The man page doesn't say about this.

You could test it for your self: build an elaborate list of ingress and egress rules across two tables of choice. Create a shell script that flushes each table, creates each chain and then loads up the the rules. Time script execution. Run 'iptables-save' on the ruleset. (Clean out the firewall and) then time 'iptables-restore'.


The only lead you've got on that is in 'man iptables-restore' the "--noflush" switch: "If not specified, iptables-restore flushes (deletes) all previous contents of the respective IP Table." which means it cleans out the previous rule set so no mixing. I can't say anything about your specific requirements of "intervening emptiness, incompleteness". If you're loading large rulesets, dynamically need to change rules and in general need more scalability than iptables can offer you might be "better" off using ipset (http://ipset.netfilter.org/features.html). For a performance comparison see http://people.netfilter.org/kadlec/nftest.pdf.

I don't see how the time it takes would tell me if it is atomic. What I want is for there to be no time frame in which a packet would be tested against the iptables in any state other than entirely before I start, or entirely after I finish. For example, when flushing, it if builds up the chain with individual rules one by one, what happens if a packet arrives in the middle of this?

What would give me confidence would be design where the entire iptables state could be pre-constructed in a temporary location, then by merely switching some internal pointer, start using the new one. Then the old one can be purged (free memory in the kernel as applicable).

The legacy way, of running multiple iptables commands from a script, certainly won't do it, since lots of stuff can happen in between those commands. But there's some gimmer of hope that iptables-restore can possibly do this, if the interface into the kernel allows constructing a temporary set of chains as described above, or if the entire state can be passed in a single syscall.

Consider this method of updating a file. You have a few places within the file to change. The changes do not change size or shift anything in position. If done as a few write-in-place operations, something could read the file between these operations and see the file in a "partly updated" state. Alternatively, you can make a copy of the file with changes done while copying, to a temporary file on the same filesystem. Then move the new file into the desired name. Any process with the old file open reads only the old file unmodified (with the only link to the file being its open link). Any process with the new file open reads only the new modified file. Nothing gets any in between state.

It was a rather crude attempt to show that if an operation takes *that* little time to complete it could be concluded it must be (near-)atomic. Maybe instead I should have suggested you read in iptables.restore.c how in main() input is parsed per line and written?.. If iptables-restore works while denying any packet traversing the firewall you could test if you have two asymmetric hosts of which you bombard and try to overload the least capable one while restoring a rule set on it.