Re: Dynamic IP hack (PR#294)

Andi Kleen (ak@muc.de)
Sun, 18 Oct 1998 19:40:14 +0200


On Sun, Oct 18, 1998 at 06:09:55PM +0200, kuznet@ms2.inr.ac.ru wrote:
> Hello!
>
> > Yep. The only contra I can and want give is that it will not be randomly
> > but for a good reason. About the code around it I have not really an
> > idea -
> > but it works. I used what was allready there and just modified the logic
> > when to do it.
>
> If I did bind() to a saddr nobody is allowed to rewrite this address.
> It is critical: if some appl. did bind, it does not want that connection were
> initiated with another address.
>
> I still assume, that someone, who enabled this sysctl has no
> such applications, so that it is not fatal, but must be commented
> and made optional.
>
> > > Could you move all this under some CONFIG_* option?
> >
> > Sure.
>
> OK.

I think that is the wrong way. Many people don't even have control over
such CONFIG_* options, because they only use a precompiled kernel. And
even when not it is hardly a binary choice, I may have some applications where
I want the feature and others where I don't want it. Fortunately there is
an easy way to detect such applications: they call bind before connect,
the others don't. So IMHO the right thing(tm) is to check if the socket
was bound explicitely and if yes don't do the rewrite. There currently
seems to be no way to do it so that needs a new per-socket flag (that
is cleaned on shutdown of course)

> > > Also, seems, this patch does not guarantee, that socket in established
> > > state is not mangled. Not good.
> >
> > It's not a bug it's the feature. :-) If bit 2 (mask value 4) of
> > sysctl_ip_dynaddr is set this does mean all packets are rewritten this
> > does include these belonging to established connections. The goal is to
> > avoid sending out packets with an invalid source address in order to get
> > atleast an RST back.
>
> I apologize, but this thing is impossible to classify as a feature.

Yes, it is not acceptable. IFF_DYNAMIC is much better @)

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/