There has been a bit of confusion about how the Nagios Plugins distribution installs the core C and script plugins. A common scenario is that the plugins are owned as the nagios user. We try to use the standard GNU tool chain mechanisms to install executables and, funnily enough, there is no documented support for installing as a specific user or group.
This is complicated by the fact that there are two plugins, check_dhcp and check_icmp, which have to be run as root, so need to be installed with the setuid bit on and the owner as root.
Looking at a few other projects, such as apache, mysql and coreutils, they have no support for installing as a specific user either – this appears to be a packaging or implementation specific task.
As a consequence, we deprecated the use of –with-nagios-user and –with-nagios-group in the 1.4.4 release, and stated that this was not a development issue.
We received lots of emails about this! Some people even thought that there were problems with compilations because a deprecated message appeared during ./configure time if –with-nagios-user was used.
Ethan Galstad also made a request that –with-nagios-user and –with-nagios-group were put back in. Initially, I resisted. Nagios is different from Nagios Plugins in that Nagios only needs to be installed on a single server – the Plugins have to be installed on every monitored box, which could be all sorts of different Unix flavours. To help with cross Unix support, we heavily use the GNU libraries, initially from the GNU coreutils source, and now directly from the Gnulib project (btw, kudos to the Gnulib team – it has become infinitely easier to sync to their libraries now. I hope we can send some patches upstream in future to show our gratitude).
By using Gnulib and the GNU tool chain (automake, autoconf, gettext, libtool [links]), we pass a lot of the burden of cross Unix support onto their shoulders. And we don’t hide the fact that we pick up lots of techniques from other projects. These projects don’t have a need to install as a specific user, so why should we?
However, after thinking about it a bit more, it seems crazy not to support –with-nagios-user/group. The ./configure for Nagios supports it, and our project is a sibling of theirs, so you would assume this was possible. Besides, I run some post-install commands to set the correct permissions – we might as well find a way of doing that in the core code. After all, the whole point about ./configure is to automate shortcuts and handle the most common use cases.
So here’s how the upcoming Nagios Plugins 1.4.7 will work:
By default at make install, the plugins will be installed with the install user’s owner and group. This reflects how other projects do their installation.
If the install user can chown an executable to root, then the root plugins will also be installed with owner root (group will be install user’s) and the setuid bit will be set.
If the install user cannot chown an executable to root, the root plugins will not be installed. However, if you run: make install-root, then the root plugins will be installed, regardless of whether the setuid and ownership could be changed – a message will appear if the chown failed, but setuid should work. We assume if you are doing this, you know what you are doing.
By the way, this is how GNU coreutils install the su binary.
./configure –with-nagios-user=USER –with-nagios-group=GROUP –without-world-permissions
You don’t have to have all three options; each works independently. –with-nagios-user and –with-nagios-group obviously set the appropriate ownership of the executables. This means that when you run make install, you must have sufficient permissions to set these users – either run as root, via some other mechanism (like sudo or fakeroot), or as the specific user (but make sure you can create the directories!). The same applies as ./configure for the root plugins – you must have some sort of root access.
Executables are installed by default as mode 0755. The –without-world-permissions will change that to 0550, to give a better degree of security, if that is what you want.
Having said all that, what do I recommend? Well, I think there’s three common cases:
Direct install (trusting)
If you are installing Nagios Plugins on your Nagios server, then the simplest way is:
# as a non root id (could be nagios) ./configure --with-nagios-user=nagios --with-nagios-group=nagios make su root -c "make install"
This is exactly the same if you are the nagios user:
su - nagios ./configure make su root -c "make install"
Direct install (paranoid)
If you want to install, but want to tighten things up and know exactly what is being run as root, do this:
# as your own id, not root nor nagios ./configure -with-nagios-user=nagios --with-nagios-group=nagios --without-world-permissions make su nagios -c "make install" su nagios -c "make install-root" # This will show an error message, though the file will be installed with setuid, but without root ownership su root -c "chown root /usr/local/nagios/libexec/check_icmp /usr/local/nagios/libexec/check_dhcp"
Of course, you could setup sudo to allow running of check_icmp and check-dhcp.
I’m assuming that if you are packaging, you have some sort of list of files which describes which ownership and mode is required. In which case, you just need the files installed in a staging area:
# as your own id ./configure --prefix=$PREFIX make make install DESTDIR=$STAGING_AREA make install-root DESTDIR=$STAGING_AREA # To force an install of the setuid plugins
This will work without the nagios user/group being created on the build server. In your list of files, you can then tell the setuid plugins to have root ownership (which can be found with
find $STAGING_AREA/$PREFIX/libexec -perm -4000).
Hopefully, this clears up the various ways of installing the Nagios Plugins, so you can get on with the business of monitoring your services…