chown -R nagios. /usr/local/nagiosxi?

[eloyd]

We used to not really care about what user owned what files inside of /usr/local/nagios because most of our sysadmin work involving Nagios was done as root. Now we have a customer where the situation is different and elevated access is strictly controlled through sudo. So we got to looking at why we can't copy localized custom css components to the nagiosxi directory tree as the nagios user. Turns out that /usr/local/nagiosxi/html/includes/components/custom-includes/css is owned by nagios, but the files in it are owned by apache. I'm guessing it's because those files were originally uploaded through the custom includes component of the XI interface, which is running under the apache user and thus owns the files.

The problem is that we need the nagios user to own those files so that subsequent, automated customization can be done (changing CSS information based on which specific server is being viewed, for instance). That customization is done via cron as the nagios user and anything that isn't owned by nagios needs to be accessed by sudo. But we can't add the ability to access arbitrary files due to STIG requirements. If the nagios user doesn't own the file, then the nagios user will not be allowed sudo access to modify the file in any way, either.

So I did some research. Turns out nagios doesn't own a few files in /usr/local/nagiosxi (including the ones uploaded via the GUI) and a huge number of files in /usr/local/nagios. My question is this:

What would be the ramifications of doing a one-time "chown -R nagios. /usr/local/nagiosxi"?

Code: Select all

# find /usr/local/nagiosxi -ls | awk '{print $5,$6}' | sort | uniq -c | sort -n
      1 nagios apache
      5 root root
      8 apache apache
      9 apache nagios
     21 root nagios
    674 nagios root
   4739 nagios nagios

# find /usr/local/nagios -ls | awk '{print $5,$6}' | sort | uniq -c | sort -n
      3 nagios nagcmd
     12 root nagios
    196 apache nagios
    704 nagios nagios
   1157 root root

[mbellerue]

That notion is a little scary. Personally, I'm not a huge fan of sweeping permissions changes. However, if this is something that needs to happen, looking over the file and directory structure, it looks like everything is either owned by nagios, apache user, or root, and the owning group is similar. As long as you make very very certain that the apache user is part of the nagios group (chown -R g+r), and that all files and directories are at least readable by group, then everything being owned by nagios:nagios should be fine.

I would probably stop all of the Nagios services before doing this. That way you're not changing ownership of lock files. I don't think that would be a particularly large problem, but best not to find out. They should remain root:root.

If this is a VM, I would highly recommend taking a snapshot prior to making the change in case you need to revert. If it's a physical box, maybe,

Code: Select all

cd /usr/local/nagiosxi/
getfacl -R -p -t * > /tmp/nagiosxi-permissions.txt

That way you'll at least have a backup of what the permissions looked like prior to making the change.

As a potential alternative, because I like playing within the system, if the files in question are owned by the apache user and group, what about doing the reverse of above and just adding the nagios user to the apache group? Would that solve the problem?

*** MODERATOR NOTE ***
(@scottwilkerson)
Several files I know of that need different permissions

Code: Select all

ls -al  /usr/local/nagios/libexec/check_dhcp /usr/local/nagios/libexec/check_icmp /usr/local/nagios/var/rw
-rwsrwxr-x 1 root   nagios 144569 Jul 12  2018 /usr/local/nagios/libexec/check_dhcp
-rwsrwxr-x 1 root   nagios 154729 Jul 12  2018 /usr/local/nagios/libexec/check_icmp

/usr/local/nagios/var/rw:
total 8
drwxrwsr-x 2 nagios nagios 4096 Sep 23 16:35 .
drwxrwxr-x 6 nagios nagios 4096 Sep 24 08:40 ..
prw-rw---- 1 nagios nagios    0 Sep 24 05:01 nagios.cmd
srw-rw---- 1 nagios nagios    0 Sep 23 16:35 nagios.qh

Pay attention to the sticky bit on these files and directory, also make sure you don't change perms on the pipe and socket

[eloyd]

Thanks to both. I should have been more clear. I put it in the title of this note, but didn't make it clear in the text of the posting.

We're not contemplating chown on /usr/local/nagios, just /usr/local/nagiosxi. Our initial examination of that (mainly to deal with uploaded custom components from XI's GUI) indicate that this is not a problem so long as group permissions are maintained as @mbellerue wrote.

And yes, we've got good recovery techniques if we royally fubar things.

[eloyd]

@mbellerue, I didn't see this part of your post because of Scott's edit:

As a potential alternative, because I like playing within the system, if the files in question are owned by the apache user and group, what about doing the reverse of above and just adding the nagios user to the apache group? Would that solve the problem?

In this case, the STIG specifies that the minimal amount of access required should be used. So adding nagios to apache group means nagios now has access to the apache config files, which won't fly. So it's easier to change permissions on the Nagios XI file tree than change permissions on users.

We're happy with changing the permissions on the files uploaded through the custom components GUI for the one-time that we need it done. The rest of my question (what happens if you chown -R nagios. /usr/local/nagiosxi) is more rhetorical.

[ssax]

@mbellerue is on point with the heavy handed approach (although I like that style for troubleshooting) but I think this should do it for both cases, correct?

Code: Select all

# Make group writable (apache AND nagios users will have access to write via the group permissions)
chown g+w /usr/local/nagiosxi/html/includes/components/custom-includes/css

# Set group sticky
chmod g+s /usr/local/nagiosxi/html/includes/components/custom-includes/css

This means that all new files and subdirectories created within the current directory inherit the group ID of the directory, rather than the primary group ID of the user who created the file. This will also be passed on to new subdirectories created in the current directory

Explanation taken from here:

https://unix.stackexchange.com/a/182225

[eloyd]

Yes, you are correct on sticky bit operation. Which is fine for the custom/css directory. I kind of got thinking at a larger scope and was wondering if there's any reason why the nagios user can't own the nagiosxi directory tree?

At any rate, we've got our STIG compliant solution and I've got some ideas I want to go test out for some other things, so if y'all want to close this topic, feel free.

[scottwilkerson]

Yes, you are correct on sticky bit operation. Which is fine for the custom/css directory. I kind of got thinking at a larger scope and was wondering if there's any reason why the nagios user can't own the nagiosxi directory tree?

At any rate, we've got our STIG compliant solution and I've got some ideas I want to go test out for some other things, so if y'all want to close this topic, feel free.

ok

Closing