Nmap Development 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----- 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? 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 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 [...] end 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 :)
Cheers,
Thanks, Kris Katterjohn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSGh83f9K37xXYl36AQLcIQ//QumbVHelnGJXNGEAgYidQOBySQZaMZru ZWPZ2lwEHENVpps/2aW8mBebdpMKmJq33lbH7xfHjJgY4T3UL+e/PfY4NvKApzU6 /vTfz2Z6hUAVPI0OQg00GgJimwv+H6arReFEdbpLRwsbLM/FNqJdUpWkUGXW2ps3 gbGt7cM+w94+2iBidU5ty2fZU29BOUBuMbNsbvvueg/6wyPcOH4CUeJSQlLq0khr snQovg4TsSnoyI+nR1HWzveRmx6WqoC5P1CwP7BKt9bIJiSPOjMgiFH5SvoX3drY IpoMNCbjPg8IgUv5ngVuM3kNcq0JOuMN5c8Jlpao6NZbZZb/RfuCTx3Kkynb0WQD JjW47Pw3OT0uRCKrIO6SYjm8A1587PZyf9ccX2zJ0M5ep59NpMkY6leOTbA9Mycj YuYN0GYISL0Lrv8vpTYj7JZ8jszi8780W9jE9J5GfQKDzdUnbEqLqzPBITcMTCth umnk/t0lL5inYolFNq9jlti3Gu4NfcuRJ/zpYR0vWRRN3SRTn8zDjKGjZTTqmP11 Dew6Wrc2EAKWWv4QJnD0+s5YazJN6mNiJODJuSiwjBM7J8D0Pvfo32BXLHcvHcY1 Aa7MU0xtQtQS/3dgVUXFcCYDWh8bneyl5h9XmRxlTZzcsMM9KXBw8mXowHTm5LZK NCbKbFpSVWM= =j5/v -----END PGP SIGNATURE----- _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- [NSE] Shared Script Environments for Threads & Universal Awareness Patrick Donnelly (Jun 29)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness Kris Katterjohn (Jun 29)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness jah (Jun 30)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness Patrick Donnelly (Jun 30)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness Patrick Donnelly (Jun 30)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness jah (Jun 30)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness jah (Jun 30)
- Re: [NSE] Shared Script Environments for Threads & Universal Awareness Kris Katterjohn (Jun 29)