[PATCH 2.6 0/12]: netfilter update
kaber at trash.net
Sun Sep 26 21:43:08 CEST 2004
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,
>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.
More information about the netfilter-devel