mailing list archives
Re: [NSE] Shared Script Environments for Threads & Universal Awareness
From: Kris Katterjohn <katterjohn () gmail com>
Date: Mon, 30 Jun 2008 01:27:44 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Patrick Donnelly wrote:
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
I'm confused about the application of _T: what environment interactivity would
a script be conducting?
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.:
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 had another idea of placing "scoped" down arguments in _S.args, but this
would have the issue of needing to check multiple places for arguments (and
placing them all there seems pointless).
When adding the "domain" argument for zoneTrans, I did this:
local args = nmap.registry.args
if args.zoneTrans and args.zoneTrans.domain then
domain = args.zoneTrans.domain
elseif args.domain then
domain = args.domain
And I'm sure many others will use similar techniques in the future if it
continues to be so long. I'd like to see something better, but my ideas
probably don't fit the bill.
Sorry for the round-about, pretty off-topic rambling, but when I started
thinking about it I was just rushed with ideas :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org