Nmap Development mailing list archives

[NSE] Shared Script Environments for Threads & Universal Awareness


From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Sun, 29 Jun 2008 21:57:16 -0600

Hey guys,

There is a change that will soon be added to NSE that concerns sharing
data between threads of the same script safely and conveniently. While
the registry is useful for sharing data between threads, it is
possible for other scripts to accidentally use the same key when
saving data. As soon as the change to give each thread its own action
closure is added, it will not possible for scripts to guarantee safety
of data in the registry programmatically.

Therefore, scripts will now have a "_S" and "_T" global available to
them for sharing data. _S(cript) is a table that can hold private data
which is shared between all threads of the same script. _T(hread) is
the environment table for the script (which will be inline with the
change to give all threads their own action closure and global
environment). Another use for the _S table is to ensure exclusion of a
mutex from other scripts. Instead of creating a mutex on the "id"
field, it could instead be done on the _S table, like so:

local mutex = nmap.mutex(_S);



Universal Awareness (comments please)

With this change I have considered a possibly useful addition to make
a thread aware of other threads running for the script. Specifically,
the _S table would hold another table, say "threads", which would be:

_S.threads = {[Thread 1] = {host, port}, [Thread 2] = {host, port}}.

This construct would allow scripts to better format output (solving a
problem discussed here:
http://seclists.org/nmap-dev/2008/q2/0897.html).

I'm interested in hearing thoughts on this.

Cheers,

-- 
-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing
to do and always a clever thing to say."

-Will Durant

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


Current thread: