系统：全新升级的 ubuntu Xenial Xerus 16.04.2。从一个干净的最小系统开始，其中只安装了 openssh。为了安装 backuppc 3.3.2，我做了以下操作：
apt-get install backuppc rsync libfile-rsyncp-perl par2 smbfs
Apt 完成了其余工作，安装了 apache2 和 perl 等依赖项。如果您认为这可能很重要，我会编辑问题并粘贴 apt 日志中的相关行。
之后，我完成了备份第一台主机所需的所有配置，几天后我回到测试实验室检查它的运行情况。我不得不说，backuppc 是一款出色的软件，它的表现完全符合我的预期，甚至比我的预期还要好！
我刚刚注意到主屏幕上池的图表没有显示；故障排除只从 apache 日志中返回了一条信息：
ERROR: opening '/var/lib/backuppc/log/pool.rrd': Permission denied
肯定是权限问题：/var/lib/backuppc 由 backuppc:backuppc 拥有，而 apache 在 www-data 帐户下运行。
通过 Google 搜索该错误，返回了以下修复：
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
这些权限更改解决了问题，现在可以显示图表了。无论如何，我仍然担心权限更改后公开服务的安全性。在这种情况下，我计划在安全和隔离的环境中实施，但如果客户要求公开服务，或者更糟的是，如果他自己公开服务，该怎么办？如果生产环境中出现问题，我不想在他们需要恢复的地方留下潜在的安全漏洞。
另一个解决方案可能是将 backuppc 的用户添加到 www-data 组，但从安全角度来看这可能更糟。
另一个解决方案可能是修补 backuppc 运行的代码来处理此类问题（并且可能是 sudoers 文件中的某些行），但我没有编程技能，也不能读懂 bash 脚本以外的任何东西。
我的问题是： 哪一个是实现图形显示最安全的解决方案？
答案1
如果该文件是唯一让您头疼的文件，您不妨将日志文件夹移动到 www-data 用户可以读取并且 backuppc 用户可以写入的位置。然后对其进行符号链接。
mv /var/lib/backuppc/log/ /var/log/backuppc/
chown backuppc:www-data /var/log/backuppc/
chmod 750 /var/log/backuppc/
ln -s /var/log/backuppc/ /var/lib/backuppc/log/
它比将您的 /var/lib/backuppc/ 完全开放给系统上的每个用户要好，特别是当该文件夹下的子目录和文件依赖于主文件夹的安全性并仅限于 backuppc:backuppc 时。
关于将 backuppc 添加到 www-data 组，不会让 www-data 访问 backuppc 拥有的文件。你的意思是反过来吗？无论如何，我同意这是一个坏主意，除非所有敏感数据只能由 backuppc 用户读取，而不能由组读取。
为什么您遵循的指南建议将 /var/lib/backuppc/log/pool.rrd 从 640 -> 754（可由所有者和组执行）而不是 640 -> 644 更改，这让我很困惑。
笔记：我已经有几年没有使用 BackupPC 了，所以我不太记得 /var/lib/backuppc 文件夹中的权限如何，或者日志目录包含的其他潜在敏感信息。
希望这可以帮助！
答案2
使用 .htaccess 限制图表访问。您只能允许您的客户端使用 .htaccess 访问。