On Thu, Jun 28, 2018 at 1:27 PM, Marko Rauhamaa <ma...@pacujo.net> wrote:
> Dan Stromberg <drsali...@gmail.com>: > > On Wed, Jun 27, 2018 at 10:31 PM, Marko Rauhamaa <ma...@pacujo.net> > wrote: > >> Dan Stromberg <drsali...@gmail.com>: > >> >> > The problem can be solved by turning on the SO_REUSEADDR flag of > >> >> > the socket. > >> > BTW, it's a security feature you're turning off. If you're on a > >> > multiuser box, it prevents a second user from stealing lingering > >> > connections from a first user on the same port. > >> > >> Can you provide a brief proof of concept? > >> > > https://stackoverflow.com/questions/19960475/problems- > related-to-so-reuseaddr > > I'm sorry but I couldn't find a working example behind the link. Could > you demonstrate the problem with a few lines of Python. It's more practical to use English: Start an echo server process P that listens on tcp/5555. Initiate a connection from a client machine to process P at tcp/5555. It works as expected. Kill P. Initiate a connection from a client machine to process P at tcp/5555. It gives a connection refused as expected. If someone else comes along soon after and starts a different echo server process Q at tcp/5555 on the same server, it starts up immediately if P used SO_REUSEADDR. Then initiate a connection from the same (or different) client machine to process P (which no longer exists). Q gets the data intended for P. Naturally, for an echo server, we're just illustrating. But if it were a daemon that supports password-based authentication, it could be a problem. As security issues go, it's not the most severe one you'll ever see. It pretty much assumes there are people on your server who you don't trust. This is not Python-specific. That's about all I have the patience for. I'm not sure I'm going to write a few programs to demonstrate the issue. It's really not a "few lines of python". -- https://mail.python.org/mailman/listinfo/python-list