我使用的是完全默认的 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那么它就会起作用。Google 建议，如果插件可以与 配合使用
munin-run，但不能与 配合使用munin-node，那么 SELinux 很可能是罪魁祸首。据我所知，我没有运行 SELinux。如果我以 root 身份在命令行上手动
service munin-node stop运行，它可以正常工作。munin-nodehtop显示插件以 root 身份运行。我可以添加一个条目/etc/munin/plugin.conf.d，并让其以主目录用户的身份运行，但这没有效果。（我的意思是，我可以看到插件现在正在运行作为该用户，但仍然会出现权限被拒绝的错误）。
我认为 Debian 脚本启动服务的方式存在问题/etc/init.d/munin-node，导致了此问题。可能是 AppArmour？
答案1
答案是，Debian 10 中的 munin-node 包包含/lib/systemd/system/munin-node.service，它设置了ProtectHome=true。Debian 9 的 munin-node 包没有这个文件。
设置ProtectHome=read-only是一种解决方案，甚至ProtectHome=false可以包含写访问权限。但是，该ProtectHome标志的存在是有充分理由的。安排插件从其他地方（外部/home）读取其数据可以说是更好的解决方案。
看这里讨论该问题以及安全性与便利性的权衡。