Linux Nach Update auf ClamAV 1.4.3 streikt OnAccess-Scan wegen fehlender Berechtigungen

[harpo]

Vor kurzem gab es für (K)Ubuntu 24.04 ein ClamAV-Update von Version 1.0.5 zu 1.4.3. Auf dem System ist OnAccess-Scan via clamonacc für den Downloads-Ordner eingerichtet. Bis zum Update funktionierte das alles auch wie es soll. Seitdem passiert beim Zugriff auf den Ordner bzw. dem Schreiben (Download) neuer Dateien nichts mehr, sondern in den Logs nur Warnungen:

clamonacc[21667]: /home/[username]/Downloads/[dateinmae]: File path check failure: Permission denied. ERROR
clamonacc[21667]: ClamMisc: Unexpected issue; Daemon failed to scan: /home/[username]/Downloads/[dateiname]

Den einzigen workaround, der zu funktionieren scheint, ist den User clamav zur Eigentümergruppe des Ordners und dessen Inhalts hinzufügen. Was äußerst merkwüdig ist, da die Eigentümergruppe die gleichen Berechtigungen hat (nur Lesen und Ausführen) wie alle sonstigen User. Und der User clamav sollte doch eigentlich unter 'Sonstige' fallen - das ist doch jeder erdenkliche User.

Damit scheint der ORdner gescannt zu werden, wenn man die CPU-Last auf den Prozessen clamd und clamonacc beachtet. Allerdings erscheint dann in den Logs folgender Eintrag:

clamonacc[20926]: ERROR: ClamCom: TIMEOUT while waiting on socket (recv)

Laut dieser Anleitung kann dies auftreten, wenn clamonacc im Zusammenhang mit dem Argumennt --fdpass verwendet wird:

Generally, if you are running clamd on the same system as clamonacc, you will be using a local unix socket and file descriptor passing is enabled by default.

Sure enough, if you run “clamonacc” without the --fdpass property it instructs “clamd” to scan files in the same way that “clamdscan” does when provided with the --fdpass property.

Das erhärtet meinen Verdacht, dass es irgendwie mit fdpass im Zusammenhang steht bzw. die automatische Erkennung für dessen Nutzung nicht richtig funktioniert. Abgesehen davon ist das Hinzufügen von User clamav zur Eigentümergruppe des angemeldeten Users auch keine saubere Lösung, zumal nicht sicher ist, ob der Scan aufgrund des socket-Timeouts überhaupt richtig funktioniert.

Falls irgendjemand Ideen hat oder gar Lösungen, weil das Problem vertraut ist, immer her damit, wäre sehr dankbar.

 

[Mornsgrans]

Vielleicht hilft der erste Treffer der Google-Suche nach "clamonacc permission denied" weiter:

Unable to run clamav/clamonacc, permission denied on files

Hi, I’m trying to setup clamav on-demand protection. I set in clamd.d/scan.conf to use a local socket: LocalSocket /run/clamd.scan/clamd.sock LocalSocketGroup virusgroup FixStaleSocket yes User clamscan OnAccessIncludePath /home/myuser OnAccessPrevention yes OnAccessExcludeRootUID yes...

discussion.fedoraproject.org

 

[harpo]

Vielleicht hilft der erste Treffer der Google-Suche nach "clamonacc permission denied" weiter:

Danke, aber nicht wirklich. Die von Dir verlinkte Seite war nur eine von etlichen, die ich zu dem Thema in den letzten Stunden durchforstet habe. Das Hinzufügen des Users clamav als auch der Gruppe clamav zu den Berechtigungen des Ordners macht hier überhaupt keinen Unterschied, es bleiben die Permisson denied Warnungen. Nur das Hinzufügen von clamav zur Gruppe des Downloadordner-Eigentümers hat wie erwähnt einen Unterschied gemacht, der aber wiederum in den nächsten Fehler führte.

Ich habe jetzt einfach mal gemacht, was man laut des ClamAV-Blogs nicht tun sollte, da es zum oben genanntenTimeout-Fehler führen soll. Nämlich in der /usr/lib/systemd/system/clamav-clamonacc.service (zu der ein symlink von /etc/systemd/system/multi-user.target.wants/clamav-clamonacc.service führt) doch einfach mal das Argument --fdpass in die betreffende Zeile eingefügt:

ExecStart=/usr/sbin/clamonacc -F --fdpass --log=/var/log/clamav/clamonacc.log --move=/root/quarantine

Damit scheint es wieder wie zuvor zu funktionieren. Keine Fehlermeldungen, der OnAccess-Scan scheint sauber durchzulaufen, Eicar-Testfile wird sauber erkannt und behandelt.
Ich muss mal die changelogs von ClamAV bzw. deren Blog durchforsten, ob sich da irgendetwas finden lässt, was auf auf das Problem schließen lässt. Die Frage ist, wo man ggf. diesen "bug" meldet, da es nicht ganz klar ist, ob das Problem bei ClamAV selbst zu beheben ist oder die systemd-Service-Datei angepasst werden muss. Da in dieser ganz oben der Kommentar zu lesen ist:

# clamonacc systemd service file primarily the work of ChadDevOps & Aaron Brighton
# See: https://medium.com/@aaronbrighton/installation-configuration-of-clamav-antivirus-on-ubuntu-18-04-a6416bab3b41#a340

, der auf die von mir im Eingangspost verlinkte Seite verweist, scheint die wohl von den Ubuntu-Betreuern des ClamAV-Pakete zu stammen.

Falls trotzdem jemand mehr weiß oder hilfreiches beizutragen hat, very welcome.

 

[Mornsgrans]

Und wie sieht es mit der Doku zu ClamAV aus?

On-Access Scanning - ClamAV Documentation

An open source malware detection toolkit and antivirus engine.

docs.clamav.net

Ich habe selbst in der Vergangenheit mehrmals erlebt, dass auf Grund neuer Features oder grundlegender Änderungen die Konfiguration in einigen Punkten geändert werden musste, damit es wieder funktioniert. Angefangen hatte es damals, nachdem ClamAV "outdated" war, es aber kein Update im Rahmen der Linux-Distribution gab und ich darum direkt von ClamAV aktualisieren musste.

 

[harpo]

Soweit ich das überblicke hat sich an der Doku nichts geändert seit April - da wurde das System neu aufgesetzt und ebenso ClamAV. Hatte ich natürlich auch vorhin schon geschaut und nix gefunden, was das Ganze erhellt hätte. Die Doku dort ist ja auch nicht wirklich Versions-spezifisch, zumindest macht sie keinen Unterschied zwischen der 1.0.x und 1.4.x Linie.