Nmap Development mailing list archives
Re: NSE Script Arguments (Was: Script selection - Gsoc)
From: David Fifield <david () bamsoftware com>
Date: Tue, 6 Apr 2010 10:06:22 -0600
On Mon, Apr 05, 2010 at 12:40:25AM -0500, Kris Katterjohn wrote:
On 04/05/2010 12:13 AM, Patrick Donnelly wrote:On Mon, Apr 5, 2010 at 12:37 AM, Kris Katterjohn <katterjohn () gmail com> wrote:On 04/04/2010 11:14 PM, Patrick Donnelly wrote:I'm undecided on whether we should strip some "identifier" for script arguments in the above code snippet. Something like this: arg["ldap-brute.username"] = arg["ldap-brute.username"] or "foo" versus arg["username"] = arg["username"] or "foo" -- the ldap-brute prefix is inferred by nse_main.lua I think I prefer the former because many scripts "share" the same argument.I don't like the former, since it's uglier than the latter and seems redundant to have the script name prefix in the argument name given to that script. I say just have the arguments with the script id in the name take precedence over the same argument without the explicit prefix. This is what I thought it was used for anyway, and to allow (as you said) for scripts to share args. The showing below assumes a user runs a script "script" and the evaluations take place in the context of "script". If a user specifies "script.user=kris" then arg["user"] => "kris" and if a user specifies "user=kris" then arg["user"] => "kris" but if a user specifies "script.user=patrick,user=kris" then arg["user"] => "patrick" since the prefixed argument takes precedence over the other when used in the context of the script "script". So the use of the explicit script prefix is transparent to the script, and I don't see a problem with this aspect.Do we have scripts that would benefit from this inheritance structure?I thought there would be more, but here's what I see off-hand: ipidseq qscan whois dns-fuzz
I think we're going to have to get away from the use of unqualified script arguments. Sooner or later, we're going to have two scripts that use "user" or "path" or "data" to mean to completely different, incompatible things. People are going to get bit after they've gotten used to using --script-args data="baz" for their favorite script, and a new release adds a new default script that also recognizes "data". The current practice of scoping the arguments with the script name is ugly, but it's the best we've come up with so far. I've been thinking about better ways to handle this. One idea I had is a syntax for --script that is like a function call --script 'dns-fuzz(timelimit=100),mysql-databases(user=dba),ms-sql-tables(user=sa)' I don't think we can get away with "--script-args user=me" in the long term. That's like setting a global variable that can have unknown effects on other scripts. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- NSE Script Arguments (Was: Script selection - Gsoc) Patrick Donnelly (Apr 04)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) Kris Katterjohn (Apr 04)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) Patrick Donnelly (Apr 04)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) Kris Katterjohn (Apr 04)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) David Fifield (Apr 06)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) Kris Katterjohn (Apr 06)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) Patrick Donnelly (Apr 04)
- Re: NSE Script Arguments (Was: Script selection - Gsoc) Kris Katterjohn (Apr 04)