Hi Samuel, > I'm ok with having our own connman chain, although this won't solve any of the > iptables existing race conditions. I know it's not really possible to solve iptables race conditions and I am not trying to fix it. But if the table is modified by the user directly, who knows what he is doing, it is simpler/nicer for him to separate its own modifications from the ones automatically handled by connman. (we don't want connman to mess up with user's rule, of course if the user messes up connman's rule... it his problem) >> Of course, when quitting connman, connman_chain gets flushed, but we >> cannot do the same for input: here is the point of atomic deletion: we >> just remove "jump to connman_chain". And we remove connman_chain then. > Atomic operations is impossible with the current iptables API. Even if you > have your own chain you could still easily hit race conditions whenever > someone is modifying your table before you commited your chain or jump > deletion. > As soon as you assume that several processes are playing with the same table, > you're lost. So here we just don't have any answer to the case where ConnMan > runs and modifies your system iptables together with other processes. If > ConnMan is managing your network, it should be the only one messing with > iptables. I did not used the term atomic in that sense ;) I was using it to explain that we are modifying the table from rule-scope. Before, it was impossible no delete one specific rule: we had to flush the chain entirely. Now we can modify on the smallest subset basis: per rule.
Cheers, Tomasz _______________________________________________ connman mailing list connman@connman.net http://lists.connman.net/listinfo/connman
