The key question is under what circumstances can a second process bind to a
port that is already bound to another process.
The original security threat that lead to SO_REUSERADDR being broken in the
1.3.60 kernel (incorrect semantics which I think still persist) was the
fact that if process A bound to port X using INADDR_ANY and SO_REUSERADDR,
a second process could bind to the specific IP addresses and obtain
connections intended for process A.
So the kernel was changed to prevent the second process from completing the
bind() call.
The problem is that in a system that has multiple IP addresses (i.e. IP
aliases or multi-homed) it is quite legitimate to have one process bound to
port X using INADDR_ANY and SO_REUSEADDR while another tries to bind to the
same port on one of the multiple IP addresses. But the fix introduce in
1.3.60 prevents this.
So we need to fix the fix. But before we actually propose an actual patch I
should like to have a discussion on exactly how the fix ought to work.
Obviously I think we can all agree that it is reasonable on a single-IP
address system that two processes ought not to be able to bind to the same
port even if both use SO_REUSEADDR and one uses INADDR_ANY. And currently
such attempts will be (correctly) rejected.
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.
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.
-- regards g.George.Pajari @ Faximum.COM * Director of Engineering * Faximum Software Inc. Faximum Messaging Server -> Fax/Email Integration * <http://www.faximum.com/fms>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/