Double escaping in $ARGx$

[Ton Voon]

On 31 Jul 2009, at 16:10, Ethan Galstad wrote:

> Ton Voon wrote:
>> I've raised a bug report in Mantis re: double escaping: http://tracker.nagios.org/view.php?id=56
>>
>> I'm convinced this is bad behaviour, but want some confirmation
>> (Ethan? Andreas?) that this is correct action before I spend the time
>> in making changes, especially as it is likely to break existing
>> configurations too.
>>
> I believe this behavior was requested by users quite a while back.
> Changing it will likely break many configurations.  Better to make  
> sure
> the current behavior is well documented, than change it I think...

Can I propose that we have a new nagios.cfg option called  
"use_backward_compatible_arg_escaping". This will default to 1 on  
configurations that do not have this set. However, new installs will  
have this configured in nagios.cfg to 0, so new systems can benefit  
from more obvious arguments, while older systems from a straight  
upgrade will work as is.

I think the change for the sample nagios.cfg will be:

# This option controls the argument escaping for host/service  
check_command definitions. Only the exclamation mark (!) will
# require escaping - everything else is passed through "as-is" to the  
check command definition. This simplifies situations where
# there are other escaped characters (such as \ or $). Macros are  
passed "as-is" to the check command definition but will be expanded
# when expanding the check command
# If you are upgrading, you should set this to 1 to retain existing  
behaviour
# The default option is 1 if this parameter is not set
use_backwards_compatible_arg_escaping=0

The documentation update for the main configuration variables will be:

If use_backwards_compatible_arg_escaping is set to 0, this will avoid  
double escaping for arguments in a host/service check_command  
definition. For example:

define command {
command_name check_nrpe
command_line $USER1$/check_nrpe $ARG1$
}

define service {
...
check_command check_nrpe!-H windows.opsera.com -c CheckFileSize -a  
ShowAll 'File:PageFile=c:\\pagefile.sys'
}


With use_backward_compatible_arg_escaping=0, the command executed will  
be: check_nrpe -H windows.opsera.com -c CheckFileSize -a ShowAll  
'File:PageFile=c:\\pagefile.sys'

With use_backward_compatible_arg_escaping=1, the command executed will  
be: check_nrpe -H windows.opsera.com -c CheckFileSize -a ShowAll  
'File:PageFile=c:\pagefile.sys'



Thomas writes:
> A bit off-topic, but I believe it would be nice to have a way to  
> execute
> commands directly rather than using the shell. I'm thinking of a
> different command option that could be used instead of  
> "command_line"...
> i.e.:
>
> command_exec $USER1$/check_dummy!1!WARNING: $SERVICEDESC$ is stale.
>
> Basically, the first argument is the full path to the executable, and
> following ones are the argument array passed to execve. Bangs (!)  
> would
> be argument separators (like in service definitions) with maybe the
> possibility of escaping them (otherwise a bang in a macro can do the  
> trick).
>
> That would give much more flexibility when complex parameters must be
> passed.


That's a good idea. I was thinking something like:

command_arg $USER1$/check_dummy
command_arg 1
command_arg WARNING

But the exclamation mark is a nice way of doing it. In fact, the  
escaping code would be the same as above, so we can reuse that. I'd  
like to add this for all host and service check commands as a new  
feature.


Andreas writes:
> Why use the exclamation mark at all? It's quite straightforward to  
> parse
> shell-style quoting into arguments, and that way users can just cut- 
> n-paste
> the commands to verify that they work (assuming they replace the  
> macros,
> that is).


That's wrong. You use execve to avoid the shell quoting and to pass in  
arguments "as-is" to the plugin without interpretation at the shell  
level. For instance:

check_command $USER1$/check_by_ssh!-H!$HOSTADDRESS$!-C!echo $PATH

The documentation for command definitions would be:

You need to specify one of command_line or command_exec. The  
command_line option will take the command specified and pass it to the  
shell before invoking. This means shell metacharacters need to be  
escaped appropriately to run as expected. The command_exec option will  
pass the command as-is to the plugin without any shell expansion.


A side effect is that you also get a performance boost too:

nagios at debian:~$ time perl -e 'for $i (1..1000) { system("/bin/true  
\"\"") }'

real 0m11.053s
user 0m1.880s
sys 0m8.829s

nagios at debian:~$ time perl -e 'for $i (1..1000) { system("/bin/ 
true","''")) }'

real 0m5.369s
user 0m0.872s
sys 0m3.912s


The 1st example forces the shell to get invoked (because of the  
quotation marks) and the 2nd is about 50% faster to invoke the  
arguments directly. Nagios uses popen but we can convert to a similar  
routine that the plugins use to capture the stdout using execve.

Ton


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20090810/90224d62/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel