Server.stop can be postponed indefinitely by a remote client keeping a connection active [Security, DoS] #5210
Comments
I would also expect that any idle connection that exists at the time server.close is called is prevented from going into timers.active. |
htp.Server#close() and net.Server#close() stop the server from accepting new connections and that's all they do. If you're worried about hostile clients, close their connections manually. Working as intended, closing. |
To stop the connections manually will also require keeping a pool of all connections, as this mechanism also doesn't exist at the moment. That is fine, but shouldn't the server.close prevent an open connection that is currently idle from becoming active again? If all future connections are prevented, shouldn't existing idle connections just be closed? |
It's actually explicitly designed (and documented) this way because no matter what scheme you think up, some kind of auto-close functionality will never cover all possible use cases (in other words, never please all people.) It's the old UNIX saw: provide mechanism, not policy. |
I'd be ok with a |
I would not be okay with that. It's a feature precious few people need but the overhead of tracking all connections is something you impose on all users. It's bad enough we have moronic stuff like net.Server#connections in there but at least that's a simple integer. There's no reason for it to be in core. It's perfectly possible to do in user land and it's not difficult either. |
Yeah, fair enough. To the npms! |
Sounds reasonable. Does the timers module track the current sockets? If that is the case, perhaps it isn't too much to ask to expose the timers list object? |
No. A timer doesn't know what type of object it's embedded in. It's not just sockets.
Not all timers are in that list. I don't want to sound unfriendly but what on earth makes you think that scanning the list of timers is the best approach to tracking connections? |
@wpreul Here you go: http://npm.im/server-destroy |
Thanks for the help with this. My point with the timers was more about the fact that there already is overhead with tracking the active sockets, so whats the harm in exposing these active sockets in some form. |
Here is the server code:
After running the server, run the following client code to keep the connection active:
Now send a SIGUSR2 signal to the server pid:
Wait forever and the server will never be shutdown. It is finally stopped when the client is closed so that the connection is closed. Here is the output:
As you can see, I let it run for about 12 minutes before finally terminating the client process. Any server that wishes to
close
can be forced to remain running. There should be a mechanism to forcefully destroy any open connections. This allows a server to optionally wait for a few seconds for connections to close and if they don't then the server can continue with a shutdown.The text was updated successfully, but these errors were encountered: