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/