Re: [BUG] NSE/Nsock filehandle exhaustion

[majek04 <majek04+nmap-dev () gmail com>]

On 8/30/07, Brandon Enright <bmenrigh () ucsd edu> wrote:
> > (It can run two times lua_yield on lua thread, but it seems that it isn't
> > bad, although it's not theoretically proper I think),
>
> I haven't been able to get it to crash so with some tweaking and further
> testing, should probably be included.

Hurray :)

> Your patch solves the Nsock handle problem in a totally different way than
> Stoiko's patch but I don't think that means that one or the other
> should be applied.  They BOTH should be applied.

I'm not sure if Stoiko's patch breaks the equality of all lua threads. As far as
I understand, one thread (the latest started?) is going to be always
served first.
On the other hand, it shouldn't really matter.

> With your patch, when the NSE loop starts, the NSOCK handles climb to 768
> in a few seconds and stay pretty pegged there until the NSE scanning
> finishes.  When this happens, the following lines are printed by the
> thousands:
>
> NSOCK: thread unqueued 0xa981f0

They are just stupid debugging messages, I forgot to remove them.

> The one concern I have with this patch is what would happen if the limit
> were set to 1 and then a single NSE script tried to make 2 sockets and
> connect on both before doing anything else.  Am I right in assuming that
> this script would deadlock because the script wouldn't be able to finish and
> close the first without the second being made to allow it to continue?  Let
> me know if this doesn't make sense or I'm just stupid.

Well, of course you're right. It means that we have to keep threshold pretty
high (to avoid deadlocks). I'm not sure if there is a need of tweaking this
threshold at runtime. Maybe it should be hardcoded to read
getrlimit(RLIMIT_NOFILE) at nmap start?

Should we hardcode nsock descriptors threshold?
or maybe it should be set to --max-parallelism?
or set to getrlimit(RLIMIT_NOFILE)*75%?


Marek Majkowski

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org