[Nagiosplug-devel] question on check_procs and shell environment

[Frost, Mark {PBC}]

>-----Original Message-----
>From: Thomas Guyot-Sionnest [mailto:dermoth at aei.ca]
>Sent: Friday, March 26, 2010 11:54 PM
>To: Nagios Plugin Development Mailing List
>Subject: Re: [Nagiosplug-devel] question on check_procs and shell
>environment
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 26/03/10 12:07 PM, Frost, Mark {PBC} wrote:
>> It seems that the check_procs configuration used on HPUX (and it looks
>like AIX although I haven't tested that one) doesn't handle command
>arguments at all, although the command implies that it does.  It uses
>"/usr/bin/ps -el" as the execution command which does not return
>arguments.  The end result is that the "command" and "arguments" values
>are to the same value (i.e. command=sh and arguments=sh) which is pretty
>useless.  -a and --ereg-arguments-array just match on the command value.
>>
>> By comparison, on Linux, these values are fully accessible.
>>
>> While you can run 'ps' on HPUX and get more fields and better sets of
>arguments, you still don't quite get them all.  There are no variants of
>'ps' on HPUX that will give all the fields that the check_procs command
>allows unless you turn on UNIX95 standards compliance.  Then you can
>make the HPUX 'ps'  function like Linux 'ps' and specify the fields you
>want.  However, this means you have to set an environment variable as in
>>
>> UNIX95= /usr/bin/ps -ex -o 'state uid pid ppid vsz sz pcpu comm args'
>>
>> I prefer to "really fix it" approach to "mostly fix it".
>>
>> check_procs calls run_cmd().  The comments in the code seem to
>indicate that the idea of passing in any environment is not allowed
>other than the single variable that is hardcoded in run_cmd_open
>(LC_ALL=C).  I changed the code to also include the "UNIX95="
>environment variable and check_procs works as it does on Linux.
>>
>> The only way I can think of to make this work reasonably is to somehow
>allow passing in this environment variable via run_cmd() say via a
>compile time options like the setting of PS_COMMAND, but it's my
>impression that this is not something that anyone wants to do for
>security reasons under any circumstances.  I think the spopen() call is
>the wave of the future for these things, but it works similarly in that
>it doesn't allow environment arguments to be passed in.
>>
>> Is this idea of passing in environment just something that is an
>impassible barrier?
>
>Hi Mark,
>
>Thank you for this very insightful explanation of the issues with
>check_procs on HPUX. Do you know if the UNIX95 trick will work on any
>decently-recent version of UX?
>

Thomas,

Honestly, I don't know.  I have the impression that this is an HPUX only
thing.  I think other vendors have just adopted the UNIX95 standard
outright.  HPUX has held back for some reason.  I think there's other
incompatibilities with some of their other tools so they opted to make
the UNIX95 support optional.  Always swimming upstream...

It appears that on AIX 5.3, the 'configure' script detects a method
to extract the fields directly like Unix does.  So perhaps the "AIX"
note in the comment for HPUX refers to much older versions of AIX.
My AIX builds seems to work OK for check_procs without additional
fiddling.

For now, I've just made a simple shell script that runs the proper
'ps' command and had check_procs call that as the PS_COMMAND.


>run_cmd() is deprecated in favour of cmd_run_array (where possible) and
>cmd_run. It seems you are using an old version of check_procs as it
>already uses cmd_run, which was changed on 2008-07-08 to fix some issues
>(best would be using cmd_run_array, although I don't think it really
>matter for check_procs).
>

I'm using 1.4.14.  I think I may have just writtn run_cmd() from memory
and, well, misremembered.  In the 1.4.14 check_procs.c, I see that
the PS_COMMAND is run with:

	result = cmd_run( PS_COMMAND, &chld_out, &chld_err, 0);

>So the best fix would be updating lib/utils_cmd.c to add functions that
>allow passing arguments (flags could also be used to determine whenever
>the environment should be added or replaced). I also think the
>environment shouldn't be erased by default as it is right now (adding
>LC_ALL=C should be the responsibility of the caller where needed...)
>

This confused me a little as the Nagios Plug-In Development Guidelines
say that spopen() should be used if external commands should be
executed (http://nagiosplug.sourceforge.net/developer-guidelines.html#AEN250).
But from looking at that function, it looks like it won't allow passing
in environment variables either.  Maybe the guidelines are outdated, but
it's not clear if spopen() or cmd_run_array/cmd_run is preferred now.

I think what I was really getting at was that in order to solve this
particular HPUX issue, you'd need to pass in "UNIX95=" to
the environment before executing the command, be it spopen() or the
cmd_open()'s ultimate execve().  But none of those support passing in
environment variables.  They cmd_open() has that one hardcoded value for
the environment and that's it.  I'm getting the impression that passing in
environment variables to such functions is considered a big security
risk and that's why none of them support it.  So if I were to consider
trying to extend one of those functions to allow passing of an env
array, am I creating a security problem that no one wants in the
plugins?

>I can help help coding that as time allow (this means I can't right now
>but keep bugging me ;) as needed!) Let me know if you need further
>detail on what I'm suggesting here.
>
>Thanks
>
>- --
>Thomas