我正在使用完全默认的 Debian Buster 安装。我已经安装了 munin-node，它报告自己的版本为 2.0.49。
我有一个自定义插件/etc/munin/plugins。它是一个 shell 脚本，它只是从用户主目录的文件中提取一个值：/home/peter/value.txt.
我可以netcat localhost 4949与 munin 节点进行交互。
如果我发出一个list命令，那么我的插件将与所有默认值一起包含在内，因此 munin-node 确实识别出该插件存在并且是可执行的，等等。但是当我尝试通过发出fetch命令来运行插件时，我得到了一个权限-插件尝试打开用户主目录中的文件时出现拒绝错误。重申；插件本身执行，但无法读取主目录中的文件。
一些事实：
它适用于 Debian 9 (Jessie)，其中 munin-node 将自己报告为版本 2.0.33-1。
如果我破解插件以打印硬编码值，它就可以工作。
用户主目录中的文件具有权限
-rw-r--r--。主目录本身具有权限drwxr-xr-x。如果我
munin-run以 root 身份从命令行安装插件，它可以正常工作。如果我移动
value.txt到/etc/munin/plugins或usr/share/munin/plugins然后它工作。谷歌建议，如果一个插件可以与
munin-run而不是与SELinux 一起工作，munin-node那么 SELinux 很可能是罪魁祸首。我没有运行 SELinux，AFAIK。如果我以 root 身份在命令行上手动
service munin-node stop运行，它可以正常工作。munin-nodehtop显示插件以 root 身份运行。我可以添加一个条目/etc/munin/plugin.conf.d并让它作为主目录所在的用户运行，但这没有任何效果。（我的意思是；我可以看到该插件现在以该用户身份运行，但它仍然出现权限被拒绝错误）。
我相信 Debian 的/etc/init.d/munin-node脚本启动服务的方式会导致这种情况。可能是 AppArmour？
答案是 Debian 10 中的 munin-node 软件包
/lib/systemd/system/munin-node.service包括ProtectHome=true. Debian 9 的 munin-node 软件包没有这个文件。设置
ProtectHome=read-only是一种解决方案，甚至ProtectHome=false包括写入权限。然而，该ProtectHome标志的存在是有充分理由的。安排插件从其他地方（外部/home）读取其数据可以说是一个更好的解决方案。有关问题的讨论以及安全性与便利性的权衡，请参见此处。