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

["David S. Miller" <davem@redhat.com>]

On Wed, 22 Sep 2004 03:42:24 +0200
Patrick McHardy <kaber@trash.net> wrote:

> The existing scheme has one problem, it takes files->file_lock
> in a BH, but the patch doesn't mean to fix this. Besides
> this, it works fine. The patch extends the owner match so it
> can also be used in the input path, where skb->sk isn't set.
> This is quite useful for filtering input traffic based on user
> etc., unfortunately it can't be done without exporting
> {tcp,udp}_v4_lookup. Do you see an alternative to dropping the
> patch ?

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.

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.