Re: Script selection - Gsoc

[Martin Holst Swende <martin () swende se>]

David Fifield wrote:
> On Thu, Apr 01, 2010 at 09:03:25PM +0200, Martin Holst Swende wrote:
>   
> > I thought a bit more about argument handling, and instead of just
> > throwing ideas around, I implemented something a bit more concrete to
> > show what I mean. I picked a script which uses arguments, it happened to
> > be dns-zonetransfer.nse.
> >
> > To that script, I added the function :
> >
> > script_args = function()
> >     return     {name="dnszonetransfer.domain", desc="Domain to transfer"},
> >             {name="domain", desc="Fallback domain to transfer if
> > dnszonetransfer.domain is not set"}
> > end
> >
> > And modified the action function by basically just removing a call to
> > nmap.registry as thus :
> >
> > action_ = function(host, port, args)
> >     local soc, status, data
> >     local catch = function() soc:close() end
> >     local try = nmap.new_try(catch)
> >    
> >     local domain = nil
> >    
> >     if args.dnszonetransfer and args.dnszonetransfer.domain then
> >         domain = args.dnszonetransfer.domain
> >     elseif args['dnszonetransfer.domain'] then
> >         domain = args['dnszonetransfer.domain']
> > ...
> >
> > As you can see, the action is now called action_ . This is because I did
> > not want to dive into nse_main.lua, but instead simulated the framework
> > by wrapping the original action in another function (which is called
> > action). So, something like this could be used by the framework to both
> > determine what arguments are used and provide help to the end-user about
> > them:
> >
> > From my view, it seems like a great benefit to have info about arguments
> > as lua-code instead of relying on parsing tags from a bunch of files.
> > The only drawback as I see it is that all scripts with comments need to
> > be modified - but probably only very minor, but please correct me if I
> > am wrong. Comments?
> >     
>
> Making script arguments defined by code not comments--as we do for
> description and categories--is a sensible design decision. There would
> have to be a way to get arguments from included libraries too.
>   
Yes, but I guess that could be done in a similar way? Another thought, if we
handle parameters 'centrally', would be that interactive mode could be
resurrected :)
Something like :

nmap --script ldap-* --script-interactive <some hosts>
ldap-brute: "ldap.base" argument missing :
       If set, the script will use it as a base for the password
       guessing attempts. If unset the user list must either contain the
       distinguished name of each user or the server must support
       authentication using a simple user name.

Please enter a value for ldap.base on host <host 1> (or Escape to skip
this script):


> I don't like adding an extra parameter to action; isn't the pretty much
> the same as nmap.registry.args? Also it puts args at a different
> parameter index for portrule and hostrule scripts, which is a little
> awkward but maybe it doesn't bother people. 
Well, I don't have any strong objections, but for two reasons I think
action() is slightly better :
* For developers new to nse : action() is like the main() of other
languages, and it makes sense to get
arguments there. It is less obvious to go digging into nmap.registry,
and requires a bit more digging into docs.
* Having arguments served in action() ties argument handling stronger to
the script-writers definition of valid arguments, which
lessens the risk of people ignoring to implement the argument definition
or keep it updated when code changes. Nmap.registry could still be a
'backdoor' to
get the arguments, but could be phased out gradually.

> But the overall idea is
> something I can support. --script-updatedb could then put args in
> script.db and Zenmap could parse it.
>   
Exactly, it will solve usability issues for console and make
zenmap-transition easier.
/Martin
> David Fifield
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
>   

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/