System: fresh and updated ubuntu Xenial Xerus 16.04.2. Started from a clean minimal system where only openssh was installed. In order to install backuppc 3.3.2 i did the following:
apt-get install backuppc rsync libfile-rsyncp-perl par2 smbfs
Apt did the rest, installing dependencies such as apache2 and perl. If you think it might be important I'll edit the question and will paste relevant lines from apt logs.
After that, I did all the configurations needed to backup the first host, and after a few days I came back to the test lab to check how it was doing. I've got to say that backuppc is a beautiful piece of software and it did exactly - or even better than - what I expected!
I just noticed that on the home screen pool's graphs didn't display; troubleshooting returned me just one piece of information from the apache logs:
ERROR: opening '/var/lib/backuppc/log/pool.rrd': Permission denied
Definitely a permissions issue: /var/lib/backuppc is owned by backuppc:backuppc while apache runs under the www-data account.
Googleing for the error returned such fix:
Resource | Actual perms | Solution's perms
/var/lib/backuppc | 2750 | 2751
/var/lib/backuppc/log | 750 | 751
/var/lib/backuppc/log/pool.rrd | 640 | 754
These permissions changes fixed the issue, and now the graphs are displayed. Anyway I'm still concerned about the exposed service's security after the permission changes. In this case i'm planning an implementation in a secure and isolated environment, but what if the customer asks to expose the service, or worse if he exposes it by himself? I don't want to leave a potential security hole right where they will go for recovery if something goes wrong in the production environment.
Another solution might be to add backuppc's user to the www-data group, but that might be even worse from a security perspective.
Another solution might be to patch the code run by backuppc to handle such issue (and, maybe, some lines in the sudoers file) but I have no programming skills, nor I can read anything but bash scripting.
So my question is: Which one is the most secure solution in order to achieve graphs display?
If that file is the only one causing you headaches, you might as well just move the log folder to a place where the both the www-data user can read it and the backuppc user can write to it. Then symlink it.
It beats opening up your /var/lib/backuppc/ entirely to every user on the system, especially if sub-directories and files under that folder relies on the security of the main folder being restricted to backuppc:backuppc only.
Regarding adding backuppc to the www-data group, would not let www-data access the file owned by backuppc. Did you mean the other way around? In any case, I would agree that it would like a bad idea, unless all sensitive data is readable by the backuppc user only and not the group.
Why the guide you followed suggested changing /var/lib/backuppc/log/pool.rrd from 640 -> 754 (executable by owner and group) and not 640 -> 644 beats me though.
NOTE: It's been a few years since I've used BackupPC, so I don't quite remember how the permissions were in the /var/lib/backuppc folder, or other potentially sensitive information the logs directory contains.
Hope this helps!
Restrict the graph access using .htaccess. you can only allow access to your clients using .htaccess.