Jan Engelhardt wrote: > On Thursday 2010-04-01 13:09, Patrick McHardy wrote: > >>> Conntrack loops are prevented by using a dummy conntrack, just as >>> NOTRACK does. >> [...] >>> - When the cloned packets gets XFRMed or tunneled, its status switches >>> from "special" to "plain". Doing policy routing on them does not seem >>> so far-fetched. >> My question was about the case without conntrack. > > Hm. Do you have any suggestion in countering a case whereby a user > does -I OUTPUT -j TEE without conntrack? > > Perhaps making nesting a feature that requires conntrack, such that the > non-CT case can't loop? If we drop the reentrancy thing, what should work is to prevent using loopback as output device and using something similar to the recursion counters tunnel devices used to have. >>> I can think of a handful of applications: >>> - CLASSIFY >> Good point, you should probably reset a couple of skb members >> after the skb_copy(). > > I take it you mean > > nf_reset(skb) > skb->mark = 0; > skb_init_secmark(nskb); Yes, basically. Although I believe the selinux people would be happier if you kept the original secmark for the copied packets :) > Or should we be using skb_alloc and copying the data portion over, like > ipt_REJECT does since v2.6.24-2931-g9ba99b0? I guess pskb_copy() would be most optimal since we can modify the header, but the non-linear area could be shared -- 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
