Messages in this thread | | | Subject | Re: Can We Agree on How to Fix SO_REUSEADDR? | Date | Mon, 15 Feb 1999 12:00:34 -0800 (PST) | From | (George Pajari) |
| |
According to Andi Kleen: > George.Pajari@faximum.com (George Pajari) writes: > > > Conversely, if the system has n IP addresses (n > 1) then one ought to be > > able to have one process listening on port X with INADDR_ANY and up to n-1 > > processes listening on the same port X but not using INADDR_ANY. > > Unfortunately, this case is not currently supported and it is this case I > > want to fix. > > I don't think it is reasonable. If you want your application to only bind > to some addresses (like the "limited INADDR_ANY" you propose) you should > change the application to bind to all addresses it is interested in.
First (and less importantly) without using user threads I am not sure it is possible to bind and listen to multiple addresses in a single server app (but that may just be my ignorance of the socket API).
Second, and more importantly, why break the previous semantics of SO_REUSEADDR which permitted one to write a server to bind to all addresses not already claimed without having to know all the possible addresses that the system might respond to?
Thirdly, when the application(s) binding to INADDR_ANY are written by others, using SO_REUSEADDR to enable overlapping bind requests may be the only option.
For example, take a multi-homed system running an email server and web server (ports 25 and 80). It ought to be possible, without rewriting sendmail or the web server to launch an application (with the appropriate permissions, of course) that handles SMTP or HTTP requests on a specific address while letting all the others be handled by the existing daemons.
This is possible on all other Intel UNIX/POSIX systems I know of. It is no longer possible in Linux since SO_REUSEADDR was broken.
> Also adding special cases for single or multiple IP systems is a bad kludge, > because it violates the principle of least astonishment.
One might argue that since Linux is the only operating system (to my knowledge) that breaks SO_REUSEADDR in this manner it is Linux that is violating the principle of least astonishment. NetBSD, SCO UNIX, UnixWare, etc. all permit (under controlled circumstances in some cases) overlapping bind requests.
Similarly, one could argue that the behaviour of preventing overlapping bind requests in Linux is a kludge to prevent a relatively rare security hole that ought to be addressed using a more elegant solution rather than disabling a major function of SO_REUSEADDR.
> Allowing other applications to steal packets is not acceptable, no > matter how many IPs anyways.
Who is talking about stealing packets? I'm sure we can design the SO_REUSEADDR semantics that will permit overlapping bind requests without packets being "stolen". That is why I posed the question of how to best restore the semantics of SO_REUSEADDR while addressing any security concerns. (For example, one could permit overlapping bind requests only when all the processes were of the same user id.)
Let us not fix one problem ("stealing packets") by creating another (breaking SO_REUSEADDR).
> > But before I start putting together an actual kernel patch I want to see if > > there are any cases that need to be considered or other opinions on how > > SO_REUSEADDR support ought to be designed. > > Don't change the meaning of INADDR_ANY. If an application does not want > INADDR_ANY it should not use it (but bind explicitely to the IP addresses > it wants instead). But if it asked for INADDR_ANY it should get it, without > any trapdoors.
I guess we differ on what INADDR_ANY means. UNIX and other non-Linux systems interprete INADDR_ANY as bind to any address not already bound. Linux seems to interpret INADDR_ANY as INADDR_ALL, i.e. bind to all addresses.
It is Linux that has changed the meaning of INADDR_ANY and I am arguing that it ought to be restored to the semantics enjoyed on other POSIX/UNIX systems.
-- regards g.
George.Pajari @ Faximum.COM * Director of Engineering * Faximum Software Inc. Faximum Messaging Server -> Fax/Email Integration * http://www.faximum.com/fms
- 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/
| |