>>>>> "HoraPe" == horape <horape@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
HoraPe> Yes, and no. Why won't just allow binding to a "more specific"
HoraPe> address if the new proccess wanting to do that binding is running
HoraPe> with the same uid that the older one? (that's afaik how the
HoraPe> 4.4BSD worked, I want to know why that was changed)
BSD never quite worked that way.
NetBSD, at least, has the same behaviour now. (I don't have another
*BSD system handy at the moment)
The same program can not bind both the wildcard and a specific one
unless, on the first bind(), it does SO_REUSEPORT. NetBSD 1.4's bind(2)
says:
SECURITY CONSIDERATIONS
bind() was changed in NetBSD 1.4 to prevent the binding of a socket to
the same port as an existing socket when all of the following is true:
o either of the existing or new addresses is INADDR_ANY,
o the uid of the new socket is not root, and the uids of the cre-
ators of the sockets are different,
o the address is not a multicast address, and
o both sockets are not bound to INADDR_ANY with SO_REUSEPORT set.
This prevents an attack where a user could bind to a port with the host's
IP address (after setting SO_REUSEADDR) and `steal' packets destined for
a server that bound to the same port with INADDR_ANY.
Canadian Commuter Challenge Project -- GNU Potato Caboose
Michael Richardson, Sandelman Software Works, Ottawa, ON
EMAIL: mcr@xxxxxxxxxxxxxxxxxxxxx
for help, email or page at 1-866-231-8608
|