6

I am on a completely default Debian Buster installation. I have installed munin-node, which reports itself as version 2.0.49.

I have a custom plugin in /etc/munin/plugins. It is a shell script that simply cats a value from a file a user's home directory: /home/peter/value.txt.

I can netcat localhost 4949 to interact with the munin node.

If I issue a list command then my plugin is included along with all the defaults, so munin-node does recognize that the plugin exists and is executable, etc. But when I try to run the plugin by issuing a fetch command, I get a permission-denied error when the plugin tries to open the file in the user's home directory. To reiterate; the plugin itself executes, but fails to read the file in the home directory.

Some facts:

  • It works on Debian 9 (Jessie), where munin-node reports itself as version 2.0.33-1.

  • If I hack the plugin to print a hardcoded value, it works.

  • The file in the user's home directory has permissions -rw-r--r--. The home directory itself has permissions drwxr-xr-x.

  • If I munin-run the plugin from the command line as root, it works correctly.

  • If I move value.txt to /etc/munin/plugins or usr/share/munin/plugins then it works.

  • Google suggests that if a plugin works with munin-run and not with munin-node then SELinux is likely to blame. I am not running SELinux, AFAIK.

  • If I service munin-node stop and run munin-node manually on the command line as root, it works correctly.

  • htop shows that the plugin is run as root. I can add an entry to /etc/munin/plugin.conf.d and have it run as the user whose home directory it is, but that has no effect. (By which I mean; I can see that the plugin is now running as that user, but it still gets a permission-denied error).

I believe there is something about the way the service is started by Debian's /etc/init.d/munin-node scripts that is causing this. Possibly AppArmour?

peterpi
  • 261
  • 1
  • 7

1 Answers1

10

The answer is that the munin-node package in Debian 10 includes /lib/systemd/system/munin-node.service, which sets ProtectHome=true. Debian 9's munin-node package does not have this file.

Setting ProtectHome=read-only is one solution, or even ProtectHome=false to include write access. However the ProtectHome flag exists for good reasons. Arranging for the plugin to read its data from elsewhere (outside of /home) is arguably a better solution.

See here for discussion of the problem as well as the security-vs-convenience tradeoff.

peterpi
  • 261
  • 1
  • 7
  • Thank you. I know I was close as if my plugin-conf.d/munin-node setting for my plugin to run as root was there id get "permission denied" but with it "file not found" whehn accessing files by chance in my home/user dir. it seemed so strange as it should be running as root and no problems, but it was this debian systemd setting blocking it. thanks, i will instead just store my files for munin stats elsewhere. – Hayden Thring Dec 30 '21 at 10:23