$HOME is not set correctly for plug-ins

[Andreas Ericsson]

On 11/25/2010 09:18 PM, Alexander Haas wrote:
> On 25.11.2010 11:39, Andreas Ericsson wrote:
>> On 11/25/2010 12:12 AM, Alexander Haas wrote:
>>> I think it's Nagois
>>> doing some kind of su in its internals which causes my plug-in to get a
>>> wrong $HOME inherited. The bad behavior only occurs when executed by the
>>> actual Nagios setup.
>> Nagios just drops privileges. It doesn't handle parsing environment
>> variables already set by the user. And for all it knows, it could
>> be wrong if it tries to do so.
>>
>> You could set whatever vars you want in /etc/sysconfig/nagios though
>> and have them work properly for every check Nagios runs. You can use
>> shell from there, so
>> HOME=~nagios
>> would be perfectly valid.
>>
>> The /etc/sysconfig thing only works on reasonably recent versions of
>> Nagios btw, but setting the vars in the init-script would have much
>> the same effect.
> So this is an expected behavior for every privileges dropping daemon?
> 

Yes. Most of them don't run a ton of other programs though.

> Well, I can live with the workaround for now.

It's not a "workaround for now". It's something you'll have to use more
or less indefinitely if you want to be able to use $HOME from plugins.

> And I don't understand
> your recommendations: /etc/sysconfig sounds like a SuSE/Yast concept to
> me. I use Debian.

It's where daemons init-files can source in extra parameters for the
daemon to use before actually launching the daemon. It's the typical
place to set up basic shell environment things. If debian doesn't have
it, it will have something like it, or you should simply complain to
debian.

> I don't know if the init-script would be the right
> place. If I understand it correctly, "$NagiosBin -d $NagiosCfgFile" does
> start the daemon. So Nagios drops the privileges itself. Therefore I
> would need a "HOME=~nagios" before I start the daemon and a "HOME=~"
> right after it.

No, you would not. A simple "HOME=~nagios $NagiosBin -d $NagiosCfgFile"
would set HOME to ~nagios for only that process. Besides, if you want
environment variables you set to be inherited by the parent process,
you need to export them.

> I do not know if there is any other impact on other
> parts of Nagios (ofc there _should_ not be any ;). So I think the most
> clean way to go is my workaround in the script itself. At least it will
> work stable for any upgrades because I do not need to touch distributed
> files.
> 

Everything that reads the $HOME environment variable. Nothing in Nagios
core anyways.

> I wonder why there is no better way to go. Some file executed before and
> after every plug-in or anything like that would be great for a whole
> bouquet of possibilities.
> 

And it would also be horrible for performance, but you can make that happen
if you want. Just write a nebmodule for it.

> My Nagios is rather old (2.4).
> 

Ouch. Any particular reason why you're not at least on the latest 2.x
version?

> Thank you for confirming my assumptions about what is happening,
> 

You're welcome.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null