Re: NSE Script Arguments (Was: Script selection - Gsoc)

[David Fifield <david () bamsoftware com>]

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/