Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



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

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

From: jah <jah_at_zadkiel.plus.com>
Date: Tue, 01 Jul 2008 21:14:26 +0100

On 01/07/2008 20:31, Kris Katterjohn wrote:
> Patrick Donnelly wrote:
> > On Mon, Jun 30, 2008 at 6:18 PM, jah <jah_at_zadkiel.plus.com> wrote:
> >>> 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
> >> I'm for _R too!
> >> whois.nse has:
> >>
> >> nmap.registry.whois.cache[host.ip].data
> >>
> >> which has to be writeable from all threads so cannot be copied into a
> >> local variable with a shorter name.
> >>
> >> _R.cache[host.ip].data
> >>
> >> would be much nicer...
> > This can and should be solved by local variables.
>
> > local registry = nmap.registry;
> > local args = registry.args;
>
>
> That's like what I did for zoneTrans, and my point is that it's pretty
> lame
> that a bunch of scripts will have to do the exact same steps when the
> solution
> can be built-in somehow. Like I said, I'm not pulling for any individual
> change (as much as I like the simple _R), but surely something can be done
> without requiring the scripts to handle the workaround for excess
> typing and
> what is IMO ugliness.
I should have said so more accurately, but in the example I gave, the
value is a shared one and that value should be read/writeable by any
thread. That is, If thread A writes to it and thread B reads it, B sees
what A wrote and vice versa. Unless I'm mistaken (and I'm going to feel
pretty silly if I am), copying some part of the registry to a local
variable removes this ability. I thought that the whole point of
nmap.registry is to allow data to be shared between scripts and, after
recent changes, is now the only way to share dynamic data between
threads of the same script.
I've not missed something fundamental have I?

Regards,

jah

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

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos