Do not launch a shell for each check

[Thomas Guyot-Sionnest]

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

On 10-10-04 05:28 AM, Andreas Ericsson wrote:
> On 10/04/2010 06:33 AM, Thomas Guyot-Sionnest wrote:
>> FWIW I've suggested something like that for a long time but never got
>> around coding it. I think we should use a different command type (i.e.
>> two possible command line option, either one of them and never both
>> would be required). Just like for command arguments, they could be
>> separated with "!".
>>
>> For example take my (slightly complex) SNMP load average command:
>>> command_line $USER1$/check_snmp -H $HOSTADDRESS$ -o .1.3.6.1.4.1.2021.10.1.3.1,.1.3.6.1.4.1.2021.10.1.3.2,.1.3.6.1.4.1.2021.10.1.3.3 -w $ARG1$ -c $ARG2$ -C $USER5$ -l 1min: -l 5min: -l 15min: -l Load -D ", " -m UCD-SNMP-MIB
>>
>> It could be rewritten as:
>>> command_exec $USER1$/check_snmp!-H!$HOSTADDRESS$!-o!.1.3.6.1.4.1.2021.10.1.3.1,.1.3.6.1.4.1.2021.10.1.3.2,.1.3.6.1.4.1.2021.10.1.3.3!-w!$ARG1$!-c!$ARG2$!-C!$USER5$!-l!1min:!-l!5min:!-l!15min:!-l!Load!-D!, !-m!UCD-SNMP-MIB
>>
>> This also allow passing empty arguments and doesn't require nagios to do
>> any single/double quote parsing, which could break some complex command
>> definitions (that would likely be much easier to write in the _exec form
>> anyway...)
>>
>> And I think the same would be beneficial for NRPE as well, allowing at
>> the same time to safely pass arguments using the exec form...
>>
> 
> Parsing arguments is not that hard, and if we run into pipes and sub-shells
> we can always fall back very easily to running
> 
>  const char *cmd_args = {"sh", "-c", cmd}
>  execv("/bin/sh", cmd_args);
> 
> but only if we keep the command-line separated with spaces instead of
> exclamation marks. Otherwise the tricky case will still have to be parsed
> for escaped exclamation marks.
> 
> Don't go down this road. It adds complexity and breaks compatibility for
> no real gain.

I'm talking about an explicit command type, like "command_exec" instead
of "command_line". Actually that doesn't even block you from
implementing this for the original command_line when you don't need a
shell, but using a different command type won't have any
backward-compatibility issue.

> I like the original suggestion though. Parse quotation marks (double
> and single) and if we hit IO redirection or subshells we just let the
> shell handle it. It's not that hard.
> 

Don't forget variable assignment/usage too... Some nagios plugins used
to be "smart" in the past and this always lead to problems... I'm not
saying it's impossible though and if you can implement it nicely go
ahead... I'll limit myself to stress-testing it ;)

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

iEYEARECAAYFAkypro4ACgkQ6dZ+Kt5BchZwwQCgj274bFJFSOudftGFwKyhPYEZ
KaUAn0g0Gti1KXOmYeeDXULzJnN3fqls
=GGg5
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security 
easier or more difficult to achieve? Read this whitepaper to separate the 
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d