Re: [NSE] Shared Script Environments for Threads & Universal Awareness

["Patrick Donnelly" <batrick.donnelly () gmail com>]

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