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

[Kris Katterjohn <katterjohn () gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/06/2010 11:06 AM, David Fifield wrote:
> On Mon, Apr 05, 2010 at 12:40:25AM -0500, Kris Katterjohn wrote:
> > On 04/05/2010 12:13 AM, Patrick Donnelly wrote:
> > > 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.

Yeah, problems are sure to arise when users aren't careful when specifying
very generic argument names without qualification.  However, I hope you aren't
suggesting that unqualified arguments shouldn't be supported; unfortunately,
it sounds like that's what you mean.

You say we have to get away from these unqualified arguments, using args like
"user=me" in the long term will cause problems, and (the kicker) your idea for
the argument syntax doesn't seem to leave any room for unqualified arguments
since the arguments are specified in --script "inside" the script name.  Maybe
I've just badly misinterpreted this? (If I somehow have, then I guess the
following can at least be here for anyone in the future who does argue against
keeping the unqualified arguments).

Please note that I'm not arguing the validity of your point regarding
arguments with names like "user" and that unqualified arguments can cause
problems.  All I want to say is that args without qualification should always
be supported unless there is a very good reason to _not_ allow them (and users
not bothering to qualify the args out of laziness shouldn't cut it).  It can
be used responsibly and should therefore stay.

The main personal reason I want them to stay supported is because I typically
scan with less than 5 scripts (often closer to 1 or 2) at a time because a lot
of the time I know exactly what I'm looking for.  Yeah, I'll do an "all" on
some new piece of equipment I'm playing with or something, but I don't even
run all of the default scripts on a regular basis.  Especially not across the
internet unless I really know the machine and have some reason for wanting
them all of run.  The two examples below show some of the problems with not
having unqualified arguments.


Your --script syntax does alleviate the following, but it's something to keep
in mind for any other suggestions or if --script-args stays: if I'm just
running a couple of scripts--say ssh-hostkey and http-methods--should I have
to use

'["ssh-hostkey"]={ssh_hostkey=full}, ["http-methods"]={retest=true}'

when

'ssh_hostkey=full,retest=true'

would be enough?  Disregarding the [""] syntax to supplement for the hyphens
in the script names (and that the ssh_hostkey name isn't exactly generic),
that is a bit much for no gain whatsoever in this case.  Surely I'm not the
only one who typically runs just a few scripts at a time!

And if I'm running mysql-{databases,users,variables}, should I have to specify
mysqluser *and* mysqlpass 3 times in --script when they all use it?  Sharing
is very handy.


Your --script syntax when used for the first example above would be like

'ssh-hostkey(ssh_hostkey=full),http-methods(retest=true)'

which is fine for that.  However it does nothing for the mysql example.  This
is one reason why I'm confused on whether you want to get rid of unqualified
arguments or not.

I mean, a lot of this is the _entire point_ behind why I always add args
checking which looks for the qualified name first, then falls back to the
unqualified name if it needs to.  Unfortunately only a small percentage of
scripts even do this (and I seem to have added the checking to most of those
that do...).

So ok: deprecate the use of unqualified arguments (with an explanation), only
use this type in examples and all of that if you wish, but scripts should
support both and it should be noted somewhere.  Using the arg[] table of
Patrick's along with my idea for the transparent scope evaluation taking place
sounds like a great way to handle this in scripts.

Plus it's easy to get long nmap commands typed up without meaning to, and
having needless extra qualifications for things like script arguments doesn't
help any.  That's not exactly of utmost importance, but still :)

Time to rest my fingers....

> David Fifield

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIcBAEBAgAGBQJLvBiSAAoJEEQxgFs5kUfuy6oP/3cbXguzY5borPs/XatK5Om1
nDkgxmLcZApkzX369fUDnbtfFaJsrh2fOE6fy74CRFJxk8/N5oDCLLzTc1h7BMh+
FdiVzG0Xz3sbR+3rvax0VzM8Dk0B16E6IB4W8oCNRRBxs6rdTEmeB8zaowLPFlNM
6b3tmPZSLhwc4k9MrGKjGV8LxwpQbPAe2VweiqGRzCG5kiNktdLfVVpgUl/2KP7k
DK3bRPPsbCHqjJDP/jsGeWyCAz8pcNQWZkBWNKWHQAmNkbuLwbCT9gXBzRLW1tDF
JOYPEZnYYFGQ8fkS6StscG146qzjLOjfxYScRX7+TKGvs8HzW53GcIr4RTZyV/L8
VyAs2BUhw4lAs3b/+cRPkn5sjzyPU1DC+Z9eY5t8ZyRf66tztaMQ9aPn9Lzhfa0W
1aDKhJ3HRb5/54/g3721pDuRgrPkWfoTQTY+SpImZzwgiC20Zg27U1QA/XQlX7NY
2oNRkyFgxFJm+yHYY448Zj28NelxIdJeg1T6tkwE/cFhf+aDzc8S221/GuVZg3d7
icD6ByjhTxUL4JHjFpz5KFZsKsA3kATDMEPHsN0Oe1CSKcRAqqs18iaPhRA0yQ2z
TFHoubqZd4Z666SglHQDd0ojLYojvnCjz/1Bl7xR+Vx4ljKLvt+ZVnG6FAGS91zr
2j07XZapQzvwOQBGeWoc
=q0pS
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/