OT: Munin Plugins können Daten nicht außerhalb von /var/lib/munin lesen
Hallo zusammen, ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden. Ich meine die Antwort war AppAmor. Da ich nun schon einige Plugins für Munin erstellt habe, wird es langsam aufwendig die jeweiligen Datenfiles doppelt zu halten. Die Scripte, die die Datenfiles erstellen, laufen alle auf dem Host, auf dem auch Munin läuft. Ich kann sie natürlich nur nach /var/lib/munin schreiben, aber das widerstrebt mir. Da die Datenfiles ein User (nicht munin) auf dem Munin-Server erstellt, habe ich die Daten auch unter der User-Directory abgelegt. Und von dort muss ich sie auch nach /var/lib/munin kopieren. Was spricht dagegen, es so zu ändern, dass die Plugins von munin überall ihre Daten lesen können. Er würde ja reichen, wenn das nur für munin gilt (Falls es sonst zu unsicher sein würde). Was müsste ich wo ändern ? In /etc/apparmor.d/ habe ich sehr viele Dateien gefunden und darin nichts, was mir in dem Fall weiterhelfen würde. Was habe ich übersehen ? Danke für Tipps. Werner Franke
Am Mi., 7. Feb. 2024 um 15:52 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden.
Ich meine die Antwort war AppAmor.
Ich vermute systemd. Zumindest hier (15.5) läuft munin-node mit ProtectHome=true man systemd.exec "If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit."
Security. Gruß Martin
Am Mi., 7. Feb. 2024 um 16:02 Uhr schrieb Martin Schröder <martin@oneiros.de>:
Security.
Siehe auch https://bugzilla.suse.com/show_bug.cgi?id=1212676 für einen Workaround. Gruß Martin
Am 07.02.24 um 18:12 schrieb Ulf Volmer:
Hallo Martin, Ulf, Danke. ich habe nach ProtectHome=read-only geändert. Das funktioniert jetzt. Vorher habe ich es mit ProtectHome=true BindReadOnlyPaths=/home/admin/Data /home/admin/Buderus ausprobiert, das hat nicht funktioniert. Warum, habe ich nicht herausgefunden und zusätzliche print Ausgaben in dem Perl-Plugin haben auch nicht funktioniert. Irgendwie habe ich noch nicht herausgefunden, wie man das richtig testen kann. Gruss Werner
Am 07.02.24 um 19:26 schrieb Ulf Volmer:
OK, DAS ist ein Argument es gleich richtig zu machen. Habe also das /usr/lib/systemd/system/munin-node.service wieder in den Orginalzustand versetzt und systemctl daemon-reload gemacht. Dann in /usr/lib/systemd/system "systemctl edit munin-node.service". Jetzt meckert er herum: Editing "/etc/systemd/system/munin-node.service.d/override.conf" canceled: temporary file is empty. Muss ich "/etc/systemd/system/munin-node.service.d" händisch anlegen ? Und wird dann "override.conf" von dem systemctl Kommando angelegt ? Danke und Gruss Werner
Am 08.02.24 um 13:00 schrieb Werner Franke:
ich habe die Dir /etc/systemd/system/munin-node.service.d händisch angelegt und die erzeugte Datei ".#override.confe2a2ba25a20fe14e" nach override.conf umbenannt. Danach "systemctl restart munin-node" Er wollte jedoch vorher ein "systemctl daemon-reload" haben. Also systemctl daemon-reload systemctl restart munin-node Irgendwie ist das seltsam. Im Internet ist das anders beschrieben. https://askubuntu.com/questions/659267/how-do-i-override-or-configure-system... Und es wird noch seltsamer. Das Munin Plugin hat nämlich wieder nicht funktioniert. Die Datei /home/admin/Data/bkw-2024-02.csv wurde wieder nicht mehr gefunden. Ich habe dann festgestellt, dass die orginale Datei /etc/systemd/system/munin-node.service verschwunden war und eine fast leere /etc/systemd/system/munin-node.service.d/override.conf bringt nicht so viel. Zum Glück war der orginale Inhalt von "munin-node.service" auch in der "override.conf" enthalten, nur mit # am Zeilenbeginn. So konnte ich die "munin-node.service" wieder herstellen. Danach wieder die beiden "systemctl" Befehle oben und jetzt tut das Plugin. Eine Idee was da falsch gelaufen sein könnte ? Laut Doku hätte das alles ohne händisches Eingreifen funktionieren sollen. Ein "systemctl cat munin-node.service" liefert jetzt: # /etc/systemd/system/munin-node.service ## Editing /etc/systemd/system/munin-node.service.d/override.conf ## Anything between here and the comment below will become the new contents of the file ## Lines below this comment will be discarded ## /usr/lib/systemd/system/munin-node.service [Unit] Description=Munin Node Requires=network.target [Service] # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort # ProtectSystem=full ProtectHome=true ProtectHostname=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true # end of automatic additions Type=forking ExecStart=/usr/sbin/munin-node ExecStartPre=/usr/bin/mkdir -p /var/run/munin/ PIDFile=/var/run/munin/munin-node.pid [Install] WantedBy=multi-user.target # /etc/systemd/system/munin-node.service.d/override.conf ### Editing /etc/systemd/system/munin-node.service.d/override.conf ### Anything between here and the comment below will become the new contents of the file ### Lines below this comment will be discarded ### /usr/lib/systemd/system/munin-node.service # [Unit] # Description=Munin Node # Requires=network.target # [Service] # # added automatically, for details please see # # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort # # Ge344ndert: 08. Feb 2024 # # # ProtectSystem=full ProtectHome= ProtectHome=read-only # ProtectHostname=true # ProtectKernelTunables=true # ProtectKernelModules=true # ProtectKernelLogs=true # ProtectControlGroups=true # # end of automatic additions # Type=forking # ExecStart=/usr/sbin/munin-node # ExecStartPre=/usr/bin/mkdir -p /var/run/munin/ # PIDFile=/var/run/munin/munin-node.pid # # [Install] # WantedBy=multi-user.target Die # Zeilen wurden beim start von "systemctl edit" in override.conf erzeugt. root@hpserver (-bash) which systemctl /usr/bin/systemctl Danke und Gruss Werner
Am 08.02.24 um 16:46 schrieb Ulf Volmer:
Nach Ulf's bedenkenswerten Tipp ist das orginale munin-node.service wieder auf wundersame Weise aufgetaucht :-) Manchmal ist das mit dem Lesen halt so eine Sache... Habe also aufgeräumt und es funktioniert immer noch. Gruss erner
Am Mi., 7. Feb. 2024 um 15:52 Uhr schrieb Werner Franke <werner_franke@arcor.de>:
ich denke ich habe das hier schon mal gefragt, kann den Thread aber nicht mehr finden.
Ich meine die Antwort war AppAmor.
Ich vermute systemd. Zumindest hier (15.5) läuft munin-node mit ProtectHome=true man systemd.exec "If true, the directories /home/, /root, and /run/user are made inaccessible and empty for processes invoked by this unit."
Security. Gruß Martin
Am Mi., 7. Feb. 2024 um 16:02 Uhr schrieb Martin Schröder <martin@oneiros.de>:
Security.
Siehe auch https://bugzilla.suse.com/show_bug.cgi?id=1212676 für einen Workaround. Gruß Martin
Am 07.02.24 um 18:12 schrieb Ulf Volmer:
Hallo Martin, Ulf, Danke. ich habe nach ProtectHome=read-only geändert. Das funktioniert jetzt. Vorher habe ich es mit ProtectHome=true BindReadOnlyPaths=/home/admin/Data /home/admin/Buderus ausprobiert, das hat nicht funktioniert. Warum, habe ich nicht herausgefunden und zusätzliche print Ausgaben in dem Perl-Plugin haben auch nicht funktioniert. Irgendwie habe ich noch nicht herausgefunden, wie man das richtig testen kann. Gruss Werner
participants (3)
-
Martin Schröder -
Ulf Volmer -
Werner Franke