Leap 15.5 firewalld startet nicht

Hallo,

ich habe festgestellt, dass derzeit firewalld beim Systemstart mit einer Fehlermeldung abbricht.

Jul 22 18:58:07 localhost systemd[1]: firewalld.service: Main process exited, code=exited, status=127/n/a
Jul 22 18:58:07 localhost systemd[1]: firewalld.service: Failed with result 'exit-code'.
Jul 22 18:58:07 localhost systemd[1]: Failed to start firewalld - dynamic firewall daemon.

systemctl status firewalld.service:

@linux:~> systemctl status firewalld.service
× firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Mon 2024-07-22 18:58:07 CEST; 12min ago
       Docs: man:firewalld(1)
    Process: 1155 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=127)
   Main PID: 1155 (code=exited, status=127)

versucht habe ich noch

rpm --rebuilddb
zypper verify
zypper install --force firewalld

Die Befehle liefen offenbar problemlos durch inkl. firewalld-post-transaction-scripts und neuer Konfiguration. Aber das Problem besteht leider fort.

Beim herumspielen mit firewall-cmd habe ich herausgefunden, dass es offenbar etwas mit Python 3 zu tun hat, und zwar mit libpython3_6m1_0.

@linux:~> sudo firewall-cmd
/usr/bin/python3: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

Erzwingt man die Installation von python3, python3-base und libpython3_6m1_0, startet immerhin der Service. Allerdings funktioniert firewall-cmd dennoch nicht richtig.

sudo firewall-cmd
/usr/bin/python3: error while loading shared libraries: libpython3.6m.so.1.0: failed to map segment from shared object

Er scheint dann zwar die Bibliothek immerhin zu finden, hat aber ein Problem beim Einbinden.

Wenn man anschließend wieder ein zypper in --force firewalld versucht, steht man wieder am Anfang, d.h. bei cannot open shared object file.

Ja, ich hatte mich mal vor längerer Zeit mit Python befasst und bei den Gehversuchen auch mit pip.

Offenbar ist python3 insgesamt kaputt.

@linux:~> python3
python3: error while loading shared libraries: libpython3.6m.so.1.0: cannot open shared object file: No such file or directory

Allerdings frage ich mich dann

1. warum man etwaige Änderungen nicht mit einem Force-Reinstall der Pakete mit Zypper wieder Rückgängig gemacht bekommt.

2. Wie man Python und Lehrbeispiele mit pip im Sinne deren Erfinder so nutzt, dass es einem das libpython-Linking des Systems nicht zersemmelt...? VM?

Ich frage mich auch, ob folgendes Verhalten normal ist:

Wenn ich das libpython3.6-Paket per Force-Install installiere, taucht die Datei libpython3.6m.so.1.0.so unter /usr/lib64 auf. Dann rufe ich z.B. python3 oder firewall-cmd im Terminal auf und bekomme einen "failed to map segment from shared object"-Fehler. Im gleichen Zuge verschwindet(!!) libpython3.6m.so.1.0.so aus dem Verzeichnis /usr/lib64.

Bei nächsten Aufruf ist der Fehler dann logischerweise "cannot open shared object file". Ist das normal, dass ein fehlgeschlagenes Linken beim Aufruf eines Programms mit normalen User-Rechten zum Entfernen der Bibliothek in einem Systemverzeichnis führt? (ld?)

Hat sich erledigt.

War mal wieder Eset Endpoint AV für Linux. Update --> alles geht wieder.

Man kann zwar Eset zugute halten, dass es bereits den ein oder anderen Drive-By-Download erkannt und von der Platte geräumt hat (allerdings waren diese Schädlinge für Windows optimiert und waren unter Linux nicht funktionsfähig). Und offiziell wird seit einiger Zeit Suse nicht mehr unterstützt...

Aber dennoch: So, wie das Produkt umgesetzt ist, ist es unter Linux ja gemeingefährlich!

Es ging schon zu Beginn der Nutzung los, dass Flatpak beim Update-Ziehen das System soweit runtergebremst hat, dass nur noch hartes Ausschalten half - solange der Eset-Service eea lief. Und in der Zeit war Suse sogar noch unterstützt. Wurde irgendwann durch ein Update von Eset behoben und sogar in den Changelogs benannt

Jetzt hat es Python3 beim Linken gestört, sodass am Ende firewalld nicht mehr lief. Also hat es ein schweres Sicherheitsproblem aufgerissen!

Man hat also eine schöne, openQA-getestete und auf Stabilität getrimmte Distribution wie Leap. Und dann kommt ein Closed-Source-Binary-AV-Programm daher und macht irgendwo in den Bibliotheken, die von den 2000 Paketen installiert wurden, einen Murks. In dem Fall sogar Murks, der sich sicherheitskritisch auswirkt und den man nur per Zufall entdeckt.

Gerade weil auch der Flatpak-Bug offiziell war, frage ich mich inzwischen, ob es für einen AV-Hersteller überhaupt möglich sein kann, alle möglichen Konstellationen selbst bei nur einer oder zwei unterstützten Enterprise-Distributionen im Griff zu haben bzw. Regressionen zu vermeiden? Man hat ein definiertes und getestetes Distributions-"Gebäude", und durch irgendwelche Umstände reisst einem dann der AV wahllos irgendwelche Wandelemente raus...

Nun, ich denke ich werde Eset dennoch bis zum bitteren Ende nächstes Jahr weiter nutzen (läuft ja wieder) und das Programm bei künftigen Problemen schneller als Ursache in Betracht ziehen. Dann kommt ja sowieso von openSUSE Leap 16 mit Containerarchitektur und es ist fraglich, ob sich das mit Eset betreiben lässt (evtl. mit hohem Aufwand). Da ich in den Eset-Foren zudem gelesen habe, dass das Tool derzeit nur bis Kernel 6.3 läuft, ist es ebenso fraglich, ob man es bis dahin mit Tumbleweed einsetzen kann.

Wenn sich an der Virensituation unter Linux bis dahin nicht viel ändert, müsste es ja reichen, gelegentlich mit ClamAV irgendwelche Windows-Schädlingsleichen aus den Firefox-Ordnern zu putzen. Ansonsten wäre ich durchaus bereit, für einen guten und schnell aktualisierten Scanner auch Geld auszugeben. Wobei ich nach diesen Erfahrungen einen einfachen On-Demand-Scanner als Flatpak oder Appimage bevorzugen würde statt etwas, was sich als Service etc. tiefer ins System eingräbt.