>The first guess is to limit total number of unix
>sockets (both alive and dead) to max_files/2.
Agreed. BTW, I realized now that my backlog security fix was fixing
nothing because the malicious guy can be also on the server side and call
listen(sk, ~0) 8). I was used to think at the guy only on the client
side...
>Then one process still may eat all of them. I still have no answer.
Ok. I think we can live with that fine.
>With stream sockets we could kill orderly release semantics
>and to purge data on close, with some ugly fixes in select(),accept()
Ah I see your point now. You mean to dealloc the SYN sock in the
server-listen-queue upon close!
>to avoid random blocking. Hmm... it is not clear, how missing
Ah and now I see also the accept() deadlock, because we have wakenup
the select of the server at client-connect time, and so the server will go
for accept(), but before accept() will run, the client will have just run
close() that we would like that it removes the SYN from the server queue.
So when the queue will be in accpet() there won't be any SYN skb in the
queue anymore!
Personally I see pretty messy going to remove the SYN by hand at
client-close() time (looks really like a band-aid).
I think the cleaner thing to do is to only limit the number of sk checking
the backlog as I did, plus taking care of SOMAXCONN. My apps are all
working fine with this new behavior.
Andrea Arcangeli
-
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/