Ubuntu 16.04.2 LTS: clamdscan fehlt Berechtigung für Dateien in Home-Verzeichnis (gelöst)
- Ersteller RedBaron
- Erstellt am
Hallo
Ich verwende clamdscan mit folgendem Kommando
für das Scannen eines /home-Verzeichnis.
clamdscan gibt folgende Meldung aus:
Der Benutzer clamav ist in der Gruppe clamav eingetragen:
Welche Einstellung sollte verändert werden das diese Fehlermeldungen von clamdscan
vermieden werden ?
Eine Suche nach
in diversen Suchmaschinen
bringt Anleitungen zur Fehlerbehebung in Verbindung mit Amavis.
Diese Software habe ich nicht installiert.
MfG
RedBaron
Ich verwende clamdscan mit folgendem Kommando
Code:
sudo -H clamdscan -m -z --fdpass /home/userclamdscan gibt folgende Meldung aus:
Code:
/home/user/.Xauthority: Access denied. ERROR
/home/user/.xsession-errors: Access denied. ERROR
/home/user/.xsession-errors.old: Access denied. ERROR
/home/user/.ICEauthority: Access denied. ERROR
/home/user/.bash_history: Access denied. ERROR
/home/user/.gksu.lock: Access denied. ERROR
/home/user/.config: lstat() failed: Permission denied. ERROR
/home/user/.cache: lstat() failed: Permission denied. ERROR
/home/user/.local: lstat() failed: Permission denied. ERROR
/home/user/.gnupg: lstat() failed: Permission denied. ERROR
/home/user/.gconf: lstat() failed: Permission denied. ERROR
/home/user/.compiz: lstat() failed: Permission denied. ERROR
/home/user/.psensor: lstat() failed: Permission denied. ERROR
/home/user/.thunderbird: lstat() failed: Permission denied. ERROR
/home/user/.mozilla: lstat() failed: Permission denied. ERROR
/home/user/.dbus: lstat() failed: Permission denied. ERROR
/home/user/.macromedia: lstat() failed: Permission denied. ERROR
/home/user/.gphoto: lstat() failed: Permission denied. ERROR
/home/user/.clamtk/db/freshclam.log: Access denied. ERROR
/home/user/.clamtk/db/mirrors.dat: Access denied. ERROR
/home/user/.hplip/hp-systray.lock: Access denied. ERROR
/home/user/.adobe: lstat() failed: Permission denied. ERROR
----------- SCAN SUMMARY -----------
Infected files: 0
Total errors: 22
Time: 12.212 sec (0 m 12 s)Der Benutzer clamav ist in der Gruppe clamav eingetragen:
Code:
user@ubuntu:~$ groups clamav
clamav : clamavWelche Einstellung sollte verändert werden das diese Fehlermeldungen von clamdscan
vermieden werden ?
Eine Suche nach
Code:
lstat() failed: Permission denied. ERRORbringt Anleitungen zur Fehlerbehebung in Verbindung mit Amavis.
Diese Software habe ich nicht installiert.
MfG
RedBaron
Zuletzt bearbeitet:
Da in der Distribution Ubuntu Apparmor mit installiert und aktiviert wird
habe ich den Apparmor Dienst mit
abgeschaltet, ohne Erfolg.
Das hinzufügen des Benutzer clamav zur Gruppe sudo
und des Benutzer "user" zur Gruppe clamav bringt keine Veränderung.
im Handbuch zu ClamAV steht zur Konfiguration von clamd:
Ich habe in der clamd.conf TCP Sockets aktiviert,
da das Thunderbird Add-On Clamdrib LIN diese benötigt.
Wen ich mit dem Befehl
von TCP Sockets auf Unix Sockets wechsel, funktioniert clamdscan, jedoch Clamdrib Lin nicht.
MfG
RedBaron
habe ich den Apparmor Dienst mit
Code:
sudo service apparmor teardownDas hinzufügen des Benutzer clamav zur Gruppe sudo
und des Benutzer "user" zur Gruppe clamav bringt keine Veränderung.
im Handbuch zu ClamAV steht zur Konfiguration von clamd:
Ich habe in der clamd.conf TCP Sockets aktiviert,
da das Thunderbird Add-On Clamdrib LIN diese benötigt.
Wen ich mit dem Befehl
Code:
#dpkg-reconfigure clamav-daemonMfG
RedBaron
Berniyh
Grand Admiral Special
- Mitglied seit
- 29.11.2005
- Beiträge
- 5.206
- Renomée
- 218
Sehr wahrscheinlich ist es so, dass eine nutzerspezifische Gruppe existiert, d.h. in Deinem Fall also z.B. RedBaron (oder was auch immer dein Benutzername ist).
Die Dateien in deinem Homeverzeichnis bekommen im Normalfall standardmäßig diese Gruppe zugewiesen, wenn du also clamav zu der Gruppe users (o.ä.) hinzufügst, dann ändert das einfach gar nichts.
Umgekehrt bringt es auch nichts deinen Benutzer zur Gruppe clamav hinzuzufügen, da diese beiden Gruppen für die Berechtigungen an deinen Dateien keine Relevanz haben.
Es gibt nun zwei Möglichkeiten das anzupassen, wobei du da nicht blind vorgehen solltest.
Du kannst entweder die Berechtigung anpassen, so dass jeder darauf zugreifen kann (und damit auch clamav).
Für Dateien wäre das:
Für Verzeichnisse:
Beides ist allerdings Standard. Für die von dir angegebenen Dateien wurden andere Berechtigungen festgelegt und das aus gutem Grund, dazu gleich mehr.
Die zweite – hier wahrscheinlich bessere – Variante ist den user clamav zu deiner Gruppe hinzufügen, d.h.
Damit hebst du den user clamav in Bezug auf deine Dateien eine Stufe höher, so dass nicht mehr die letzte Berechtigungsspalte entscheidend ist, sondern die mittlere. Dann könntest du für die entsprechenden Dateien statt 644 bzw. 600 als Berechtigung 664 bzw. 660 setzen und clamav hätte Zugriff.
ABER: es gibt einen Grund, weshalb diese Dateien überhaupt andere Berechtigungen haben als das was Standard ist, nämlich dass es sich um nutzer- und session-spezifische Dateien handelt, für welche eine externer Zugriff eigentlich ausgeschlossen werden sollte.
Das bezieht sich insbesondere auf Dateien wie .Xauthority oder .ICEauthority. Dabei handelt es sich meistens um reine Textdateien, in denen virentechnisch eigentlich nichts zu erwarten ist (und die sind auch nicht ausführbar o.ä.
Im Grunde würde ich sagen, dass die einzigen Beispiele aus deiner Liste, für welche man über eine Änderung nachdenken könnte die Verzeichnisse .cache und .local
Evtl. auch .mozilla und .thunderbird.
Aber eigentlich sollte auch das nicht notwendig sein. Temporäre Dateien werden von den Browsern typischerweise in /tmp oder /var/tmp abgelegt, wenn clamav da Zugriff hat sollte das ausreichen.
Von daher lass es so wie es ist und ignoriere diese Fehlermeldungen (ok, das wäre also auch kürzer gegangen ^^).
Die Dateien in deinem Homeverzeichnis bekommen im Normalfall standardmäßig diese Gruppe zugewiesen, wenn du also clamav zu der Gruppe users (o.ä.) hinzufügst, dann ändert das einfach gar nichts.
Umgekehrt bringt es auch nichts deinen Benutzer zur Gruppe clamav hinzuzufügen, da diese beiden Gruppen für die Berechtigungen an deinen Dateien keine Relevanz haben.
Es gibt nun zwei Möglichkeiten das anzupassen, wobei du da nicht blind vorgehen solltest.
Du kannst entweder die Berechtigung anpassen, so dass jeder darauf zugreifen kann (und damit auch clamav).
Für Dateien wäre das:
Code:
chmod 644 /path/to/file
Code:
chmod 755 /path/to/directoryBeides ist allerdings Standard. Für die von dir angegebenen Dateien wurden andere Berechtigungen festgelegt und das aus gutem Grund, dazu gleich mehr.
Die zweite – hier wahrscheinlich bessere – Variante ist den user clamav zu deiner Gruppe hinzufügen, d.h.
Code:
gpasswd -a clamav RedBaronABER: es gibt einen Grund, weshalb diese Dateien überhaupt andere Berechtigungen haben als das was Standard ist, nämlich dass es sich um nutzer- und session-spezifische Dateien handelt, für welche eine externer Zugriff eigentlich ausgeschlossen werden sollte.
Das bezieht sich insbesondere auf Dateien wie .Xauthority oder .ICEauthority. Dabei handelt es sich meistens um reine Textdateien, in denen virentechnisch eigentlich nichts zu erwarten ist (und die sind auch nicht ausführbar o.ä.
Im Grunde würde ich sagen, dass die einzigen Beispiele aus deiner Liste, für welche man über eine Änderung nachdenken könnte die Verzeichnisse .cache und .local
Evtl. auch .mozilla und .thunderbird.
Aber eigentlich sollte auch das nicht notwendig sein. Temporäre Dateien werden von den Browsern typischerweise in /tmp oder /var/tmp abgelegt, wenn clamav da Zugriff hat sollte das ausreichen.
Von daher lass es so wie es ist und ignoriere diese Fehlermeldungen (ok, das wäre also auch kürzer gegangen ^^).
Hallo
@ Berniyh: Vielen Dank für die Hinweise mit den nutzer- und session-spezifische Dateien.
Das Homeverzeichnis hate ich zum Testen und eingrenzen gewählt,
weil der angemeldete Benutzer dort vollen Zugriff besitzt.
Die Dateisystem Rechte wollte ich bewusst nicht verändern,
um weitere Probleme zu vermeiden.
Ich habe clamdscan in der Vergangenheit zum manuellen Scan der NTFS Partitionen des Dual-Boot verwendet.
Dort bekomme ich die gleiche Fehlermeldung angezeigt.
MfG
RedBaron
@ Berniyh: Vielen Dank für die Hinweise mit den nutzer- und session-spezifische Dateien.
Das Homeverzeichnis hate ich zum Testen und eingrenzen gewählt,
weil der angemeldete Benutzer dort vollen Zugriff besitzt.
Die Dateisystem Rechte wollte ich bewusst nicht verändern,
um weitere Probleme zu vermeiden.
Ich habe clamdscan in der Vergangenheit zum manuellen Scan der NTFS Partitionen des Dual-Boot verwendet.
Code:
clamdscan --fdpass /media/user/<NTFS-Partition>
Code:
lstat() failed: Permission denied. ERRORMfG
RedBaron
Berniyh
Grand Admiral Special
- Mitglied seit
- 29.11.2005
- Beiträge
- 5.206
- Renomée
- 218
Es ist auch erstmal nichts daran verkehrt clam Zugriff auf das Home Verzeichnis zu geben, aber die Dateien und Verzeichnisse für die eine Fehlermeldung ausgegeben wurde müssen auch wirklich nicht gescannt werden, da kann man einen Virenbefall (Ausnahme ggf. .cache und .local) weitgehend ausschließen.
Bzgl. der NFTS Partition ist das Problem praktisch das Gleiche. Das liegt daran, dass NTFS keine Unix Zugriffsrechte unterstützt.
Du musst beim Mounten den Nutzer und die Gruppe angeben auf den das Laufwerk gemountet werden soll. Wahrscheinlich ist das standardmäßig der Nutzer der es mountet, d.h. der gleiche Nutzer und die gleiche Gruppe wie oben.
Man kann aber auch in der fstab Nutzer, Gruppe und Berechtigungen eintragen. Eine Lösung wäre es z.B. eine Gruppe ntfs zu erstellen auf welche gemountet wird und welche lesend (und ggf. schreiben) Zugriff auf die Daten hat.
Mitglied dieser Gruppe sind dann sowohl clamav als auch der Nutzer.
/media ist übrigens deprecated, sollte eigentlich inzwischen /run/media sein.
Bzgl. der NFTS Partition ist das Problem praktisch das Gleiche. Das liegt daran, dass NTFS keine Unix Zugriffsrechte unterstützt.
Du musst beim Mounten den Nutzer und die Gruppe angeben auf den das Laufwerk gemountet werden soll. Wahrscheinlich ist das standardmäßig der Nutzer der es mountet, d.h. der gleiche Nutzer und die gleiche Gruppe wie oben.
Man kann aber auch in der fstab Nutzer, Gruppe und Berechtigungen eintragen. Eine Lösung wäre es z.B. eine Gruppe ntfs zu erstellen auf welche gemountet wird und welche lesend (und ggf. schreiben) Zugriff auf die Daten hat.
Mitglied dieser Gruppe sind dann sowohl clamav als auch der Nutzer.
/media ist übrigens deprecated, sollte eigentlich inzwischen /run/media sein.
Hallo
@Berniyh :
Aus welcher Quelle stamt die Info ?
In Ubuntu ist der Mountpoint auf /media/<username> eingestellt.
http://askubuntu.com/a/214660/28216
MfG
RedBaron
@Berniyh :
Aus welcher Quelle stamt die Info ?
In Ubuntu ist der Mountpoint auf /media/<username> eingestellt.
http://askubuntu.com/a/214660/28216
MfG
RedBaron
Als erster Beitrag eine Antwort....mal schauen ob das gut gehen wird
Clamav benutzt process-forking mit normalen Nutzerrechten, weswegen clamav in der Regel keine Homeverzeichnisse scannen kann.
Der Start sieht in etwa so aus
sudo clamd <--- startet den den Process clamd "Master" mit root-Rechten
|
V
Prüft ob alle Dateien da sind, wie die Konfigurationsdateien. In der Konfigurationsdatei, in der Regel /etc/clamd.conf, steht welchen Nutzer clamd benutzen soll. Standard ist clamav
|
V
Nach erfolgreicher Prüfung wird die glibc-Funktion fork aufgerufen
|
V
Es wird ein Subprozess "clamd mit Nutzerrechten clamav" gestartet, welcher die Arbeit verrichtet, und der clamd "Master" wird gestoppt bzw. nur noch zur Kontrolle des Subprozesses benutzt.
Da jetzt der arbeitende clamd-Prozess nur noch die Rechte vom Nutzer clamav hat, kann dieser /home/MyUser nicht scannen.
Mein kleiner Beitrag zu "Wieso kann clamav nicht lesen".
Man könnte jetzt in /etc/clamd.conf den Wert "user=root" konfigurieren, was aber unter keinen Umständen getan werden sollen.
Hintergrund ist, dass ein Programm mit root-Rechten für einen Virus o.ä. viel interessanter ist, da man als oberster Admin "root" halt alles machen kann. Um die Angriffsfläche zu minimieren sind verschiedene Entwicklergruppen dazu übergegangen, ihre Prozesse genauso starten zu lassen:
- ein Masterprozess mit root-Rechten für verschiedene Dinge, wie Integritätsüberprüfung oder Portbelegung
- einer bzw. mehrere Subprozesse, welche die eigentliche Arbeit erledigen und mit normalen Nutzerrechten nicht sehr viel Schaden anrichten können
Clamav benutzt process-forking mit normalen Nutzerrechten, weswegen clamav in der Regel keine Homeverzeichnisse scannen kann.
Der Start sieht in etwa so aus
sudo clamd <--- startet den den Process clamd "Master" mit root-Rechten
|
V
Prüft ob alle Dateien da sind, wie die Konfigurationsdateien. In der Konfigurationsdatei, in der Regel /etc/clamd.conf, steht welchen Nutzer clamd benutzen soll. Standard ist clamav
|
V
Nach erfolgreicher Prüfung wird die glibc-Funktion fork aufgerufen
|
V
Es wird ein Subprozess "clamd mit Nutzerrechten clamav" gestartet, welcher die Arbeit verrichtet, und der clamd "Master" wird gestoppt bzw. nur noch zur Kontrolle des Subprozesses benutzt.
Da jetzt der arbeitende clamd-Prozess nur noch die Rechte vom Nutzer clamav hat, kann dieser /home/MyUser nicht scannen.
Mein kleiner Beitrag zu "Wieso kann clamav nicht lesen".
Man könnte jetzt in /etc/clamd.conf den Wert "user=root" konfigurieren, was aber unter keinen Umständen getan werden sollen.
Hintergrund ist, dass ein Programm mit root-Rechten für einen Virus o.ä. viel interessanter ist, da man als oberster Admin "root" halt alles machen kann. Um die Angriffsfläche zu minimieren sind verschiedene Entwicklergruppen dazu übergegangen, ihre Prozesse genauso starten zu lassen:
- ein Masterprozess mit root-Rechten für verschiedene Dinge, wie Integritätsüberprüfung oder Portbelegung
- einer bzw. mehrere Subprozesse, welche die eigentliche Arbeit erledigen und mit normalen Nutzerrechten nicht sehr viel Schaden anrichten können
Zuletzt bearbeitet:
tomturbo
Technische Administration, Dinosaurier
Frage an RedBaron: Warum verwendest Du überhaupt clamdscan und nicht clamscan?
Es ist nicht notwendig den clamd scannen zu lassen mit all seinen "Beschränkungen".
Gruppenrechte so aufzudrehen, dass sie wieder zu weit geöffnet sind machen ja aus Sicherheitsgründen nicht wirklich Sinn.
Es ist nicht notwendig den clamd scannen zu lassen mit all seinen "Beschränkungen".
Gruppenrechte so aufzudrehen, dass sie wieder zu weit geöffnet sind machen ja aus Sicherheitsgründen nicht wirklich Sinn.
Hallo
@ GTrash81: Herzlich Willkommen auf Planet3dnow.
Der Hinweis mit dem root in der /etc/clamd.conf stimmt.
Damit clamAV nur mit eingeschränkten Rechten ausgeführt wird
habe diesen Eintrag nicht eingestellt.
@ tomturbo:
Die Benutzer- und Gruppenrechte habe ich wieder auf Originalwerte zurück geändert.
Clamdscan scannt schneller als clamscan.
Du hast Recht, das clamscan diese Beschränkungen nicht hat und einwandfrei funktioniert.
MfG
RedBaron
@ GTrash81: Herzlich Willkommen auf Planet3dnow.
Der Hinweis mit dem root in der /etc/clamd.conf stimmt.
Damit clamAV nur mit eingeschränkten Rechten ausgeführt wird
habe diesen Eintrag nicht eingestellt.
@ tomturbo:
Die Benutzer- und Gruppenrechte habe ich wieder auf Originalwerte zurück geändert.
Clamdscan scannt schneller als clamscan.
Du hast Recht, das clamscan diese Beschränkungen nicht hat und einwandfrei funktioniert.
MfG
RedBaron
tomturbo
Technische Administration, Dinosaurier
Eventuell scannt clamdscan deswegen schneller weil er eben viele Dateien nicht scannt.
Ähnliche Themen
