jaraco
commented
8 years ago It seems wrong to disable the 'bind by default' behavior without at least some consideration for why that call was there. I didn't write the code from which that call originated, so I'm unsure what the motivations were at the time.
I did some searches, and I'm not exactly sure what the motivation is for allowing a client to customize the bind socket. I found this SO question which has only one useful answer. If that answer is right, and the only reason one would use bind is to specify the port, but it seems entirely plausible to me that there are other reasons. This post explains one and I surmise that binding to a specific address could also prove useful when wanting to select a particular interface.
That said, it seems to me that 'bind before connect' is an unusual paradigm that's rarely used, so probably shouldn't be the default behavior for a lib like this one.
Execution of something like
sock.bind (('127.11.210.3', 0))will give a permission denied error.
In your example, you provide a specific bind address, but your patch suggests that also execution of sock.bind(('', 0)) will give the same permission error. Is that the case?
jpbarto
Red Hat's OpenShift PaaS cloud has SELinux and firewall rules in place which make 'binding' a client socket impossible. Execution of something like
sock.bind (('127.11.210.3', 0))will give a permission denied error. If the socket is connected without first binding the socket the connection will be successful. This modification checks whether a bind address has been specified, if not specified, it does not call bind on the created socket, in order to support OpenShift deployments.