[Nagiosplug-devel] question on check_procs and shell environment

[Kyle O'Donnell]

The following works for AIX 5.3 and 6.1:

./configure --prefix=/opt/nagios --enable-perl-modules
--with-ps-command="/usr/sysv/bin/ps -eo 's uid pid ppid vsz rss pcpu
etime comm args'" --with-ps-format="%s %d %d %d %d %d %f %s %s %n"
--with-ps-cols=10
--with-ps-varlist="procstat,&procuid,&procpid,&procppid,&procvsz,&procrss,&procpcpu,procetime,procprog,&pos"


On Tue, 30 Mar 2010 11:57:30 -0400, "Frost, Mark {PBC}"
<mark.frost1 at pepsico.com> wrote:
>>-----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
> 
> 
>
------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________________
> Nagios Plugin Development Mailing List
> Nagiosplug-devel at lists.sourceforge.net
> Unsubscribe at
> https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
> ::: Please include plugins version (-v) and OS when reporting any issue.

> ::: Messages without supporting info will risk being sent to /dev/null