[users] Nagios 3.2.3 SELinux

Scott Reese sreese at bluelock.com
Wed Jan 5 16:01:47 CET 2011


I've been looking at the SELinux policy as it relates to Nagios.  It's been a learning experience, and I now fully understand why people just turn SELinux off.  What a hassle.  In any event, I've isolated the issues, and I'm looking for advice from those of you who package software around here on which way of solving the problem is best.

RedHat is shipping a Nagios SELinux policy module as part of their base selinux-policy package.  It has a few problems, some major, some minor.  The major one, which causes Nagios to not be able to start if SELinux is set to Enforcing is that the policy expects certain Nagios files to be in one place, but they are somewhere else.  The problem is in the /var directory structures.  RedHat expects Nagios to put its files into the existing /var structures.  PID files go in /var/run, spool files (which Nagios is using to get results back from the plugins) in /var/spool/nagios, etc.  The way that Nagios is packaged, however, is different.  It creates a /var/nagios directory structure, and puts all of its files in there.  Since the files aren't where the SELinux policy expects them to be, it generates denials and Nagios doesn't work.

So, the options boil down to change the Nagios packages to fit the shipping RedHat SELinux policy, or modify the SELinux policy to match the shipping Nagios package.  My question is, which do you think is the best way to go?

Yury had previously asked if the SELinux policy could be packaged and shipped with the Nagios RPMs.  The infrastructure to do that is built into the RPM packaging system, so it would be a possibility.  What I haven't figured out is how that would interact with the policy module that RedHat is shipping as part of the base package.  I don't know if RedHat would have to remove that module from the package, or if just shipping a module with a higher version number would replace the RedHat module with the Nagios module.

Thanks for any insight you have.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20110105/8f269429/attachment-0004.html>

More information about the users mailing list