Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [NSE] Shared Script Environments for Threads & Universal Awareness
From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Mon, 30 Jun 2008 20:22:20 -0600

On Mon, Jun 30, 2008 at 12:27 AM, Kris Katterjohn <katterjohn () gmail com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Donnelly wrote:
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).

I'm confused about the application of _T: what environment interactivity would
a script be conducting?

A thread may want access to its environment table. It is useful for
indexing global keys that are not strings.

Since we're using this nomenclature for script-specific information, how about
making a global _R the registry interface?  It gets pretty ugly sometimes
trying to deal with some arguments, e.g.:

nmap.registry.args.anonFTP.pass

Using _R will at least lighten that up a little bit.  And, while I admit that
having too many not-terribly-descriptive tables like this can get confusing,
it will add consistency with the new tables.

And/or maybe we could even have an _A or ARGS table, which would reduce these
extra characters, while the latter even keeps it obvious what's going on.

However, these ideas may turn out to be even uglier than the current way in
practice.  And having too many tables like _S and _T could end up being as bad
as the Perl/Ruby $ variables ($!, $_, $/, etc).

I used _S and _T because it fit well with Lua's use of _G for the
global environment. As I said in my previous post, script writers
should make local copies of the nmap registry and args tables.

Sorry for the round-about, pretty off-topic rambling, but when I started
thinking about it I was just rushed with ideas :)

I'm always open to ideas! :)

Thanks,

-- 
-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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]