Re: [PATCH 2.6 0/12]: netfilter update

[Patrick McHardy <kaber@trash.net>]

David S. Miller wrote:

>I think the scheme is a bit illogical.
>
>Until the actual TCP socket lookup call, you cannot say for sure
>what that lookup would result in.
>
>For example, let's say that between where the ipt_owner match
>is invoked on input, and the actual call to tcp_v4_rcv(), some
>filtering or other packet mangling scheme changes the IP address
>or ports.  You're going to get different results in ipt_owner()
>than TCP was going to achieve.
>
>It sounds like we want some kind of socket resolution policy check.
>It's starting to get rediculious, as we have two filters _already_
>in that code path, one for the per-socket BPF style filtering, and
>the other for IPSEC.
>
>The IPSEC check is available on output too.
>  
>

It's mainly a problem if the socket is closed or replaced between the
lookup in ipt_owner and the lookup in tcp, for the other cases you
can define the semantic as: the socket that the packet would be
delivered to if the packet is not dropped and none of the keys used
for the lookup are altered.

>I don't see how it's avoidable to add another condition there.
>So what if we had something like:
>
>	NF_SK_HOOK(PF_INET, NF_TCP_IN, sk, skb, skb->dev, NULL,
>		   tcp_v4_rcv_finish)
>
>or something along those lines?  Perhaps you can simplify the
>argument set even further.
>  
>
Unfortunately I have to agree with you, another set of hooks looks
like the only way to solve the race. Let me think some more about
the implications for iptables and ip_conntrack.

Regards
Patrick