RRD files not removed when deleting device

[laf]

When deleting a device from the web interface, the rrd files and directories aren't removed. This will be due to those folders and files being owned by the user that the poller runs as (root).

[f0o]

This can be solved with two ways...

1. suid on the rrd folder to make all (future) files be owned by the www-data (or equivalent)
2. let the poller, which is being executed as root, drop privileges before saving the rrds (or chown'ing after creation)

Method 1 would require an additional chmod step in the config.
Method 2 would require a config directive to let poller know the UID/GID.

[laf]

Does 1) do what we need?

I've just given it a quick test by creating a folder as root, setting suid then trying to create a file within that folder and it doesn't work :(

[f0o]

sorry it was sgid hehe
here a quick example on the box I'm currently on...

root@web:/var/www# umask 007
root@web:/var/www# mkdir tmp
root@web:/var/www# chown root:www-data tmp
root@web:/var/www# chmod 6775 tmp
root@web:/var/www# touch tmp/newfile
root@web:/var/www# ls -la tmp/
total 8
drwsrwsr-x 2 root www-data 4096 Nov  7 13:07 .
drwxr-xr-x 3 root root     4096 Nov  7 13:07 ..
-rw-rw---- 1 root www-data    0 Nov  7 13:07 newfile
root@web:/var/www# sudo -u www-data rm -v tmp/newfile
removed `tmp/newfile'

Note: That umask is just Quick'n'Dirty, would put more than 1s thought into it for productive ;)

[laf]

I'm struggling to get this working in an install, when the rrd directory is created the permissions still don't include group write access for www-data (apache in my case) to remove the directory. The rrd files within are also created with permissions which won't allow the web server user to remove them :(

[paulgear]

To me, it seems easier simply to mark the host as deleted, then let the poller clean up the RRDs and remove the entry from the database.

[f0o]

shell_exec("rm -rf ".trim($config['rrd_dir'])."/$host");

This is included in delete_device($id) (File: includes/functions.php Line: 249)

So really the fix relies in POSIX permissions.

I suggest:

1. create a librenms user
2. add the httpd's user to the librenms group
3. let the cronfile run with that uid/gid
4. let the poller chmod 775 all new files

If that's too much to ask for, we can add a very ugly chmod 777 over all newly created rrds. I wouldnt like this!

[paulgear]

Let's just forget you ever mentioned chmod 777 and move along. :-)

[laf]

lol, also those steps are manual for existing installs.

What about dealing with it in the poller like blahdeblah said? May require another column to the DB though.

[f0o]

yes, it requires another column. Not that it would be an issue, I just think that on the long-run we shouldnt let the poller run as root... it's not really sane...

[paulgear]

I fully agree that running the poller as root is undesirable, but I think that it may have to due to use of fping.

[f0o]

@paulgear : fping has suid flag on upstream debian and centos. This shouldnt be an issue then

I also recall somebody on the IRC saying he uses the cron as nonroot already.. Will ask for bugs or wether it works outofthebox

[f0o]

Shorty from IRC said it worked outofthebox, he's running the cronjobs with same user as his apache.

[laf]

Is it worth looking at how we can migrate people to running as a non-root user?

One of the challenges will be that we had in the docs to symlink the cron file for quite a while, this means if we updated that file then it would break a lot of installs. We could have a second cron file we reference from now on and have that as part of the instructions creating a librenms user (people can change this user).

Thoughts?

[paulgear]

I agree - we need to aim for migrating the poller to non-root.

[laf]

@f0o would you mind re-opening the PR you did for this with a few changes:

create a new file called cron.librenms (or another name that fits?) and also add a note to the top:

# Using this cron file requires an additional user on your system, please see install docs.

update the install docs to tell people to copy that new file rather than librenms.cron

Add a note into librenms.cron that says:

# It's recommended not to run this cron anymore - please see cron.librenms

[laf]

Ok, tested. works fine. Current installs will continue to function but instructions show how to install with separate user.

[f0o]

So, Closing?

[laf]

Yeah :)

[laf]

Actually, still having issues with it removing rrd files :/

[laf]

So @f0o actually I've had to make some changes. The device I tested it on had lax perms so it just deleted :/

umask(0000);

chmod 776 rrd/

With those it now works for me - thoughts?

[laf]

All sorted thanks to @f0o :)

[f0rkz]

This is still an issue FYI

[robimarko]

Yeah,just messed whole graphing for me.
After I deleted device all of graphing just broke.

[smounives]

still have this issue

[f0o]

It's most definitely a config issue. Be sure that the user running the GUI has enough privileges to delete files created by the librenms user.

[murrant]

FYI, from new install docs:

chown -R librenms:librenms /opt/librenms
setfacl -d -m g::rwx /opt/librenms/rrd
setfacl -R -m g::rwx /opt/librenms/rrd

#SELinux
semanage fcontext -a -t httpd_sys_content_t '/opt/librenms/rrd(/.*)?'
semanage fcontext -a -t httpd_sys_rw_content_t '/opt/librenms/rrd(/.*)?'
restorecon -RFvv /opt/librenms/rrd/

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed.