Unbekannter legt Log mit nutzerverhalten an

[hoppla]

Hallo,
Mit welchem Programm kann ich einen Übeltäter Dingfest machen?

Ich benutze jessie mit XFCE, als Browser iceweasel.
Nach jedem Neustart wird mit Bleachbit aufgeräumt, vor dem Herunterfahren des Lappi wir läuft Bleachbit noch mal durch.

Welches Proramm , Suchmaschine legt trotzdem nach jedem Neustart ein Verzeichnisse mit 2 Dateien mit Nutzerverhalten (heruntergeladene Dateien) an?
Die verzeichnisse liegen unter /home/<user>/.local/share/ und haben nach jedem Neustart einen anderen
Buchstaben (machmal auch eine Zahl) als Verzeichnisnamen.
Die Dateinamen sind immer home und home.log, zB. /home/<user>/.local/share/J/home und home.log

Wie ermittle ich den Übeltäter , wie verhindere ich diese unzulässige Bürgerbespizelung,
schließlich gilt die Regel "Nicht ohne meine Erlaubnis!"

[pferdefreund]

Eventuell geht da was mit inotify ?

[hikaru]

Was steht denn in dem home.log drin? Vielleicht gibt das Aufschluss über den Erzeuger.
Auf einem von einer Jessie-Minimalinstallation hochgezogenen Xfce-System habe ich sowas übrigens nicht. Heute Abend kann ich mal auf einer Xfce-Standardinstallation nachschauen.

[smutbert]

Ich habe hier eine ziemlich fette Testinstallation mit Gnome, KDE, Xfce und Mate, bei der ich jeden Desktop zumindest ausprobiert habe und kann auch keine derartige Datei finden - hast du irgendeine exotische Anwendung installiert?

[MSfree]

lsof könnte auch nützlich sein, um heraus zu finden, welches Programm die gerade erzeugten Dateien geöffnet hat.

z.B.:

lsof | grep Dateiname

[hoppla]

So, ich habe ein bisschen rumprobiert.
im ersten Schritt habe dafür gesorgt dass keine Verzeichnisse mit Buchstaben oder Zahlen
unter .local/share/ vorhanden waren.

Neustart, Kontrolle auf Veränderungen in .local/share/home/ nix drin.
iceweasel gestartet und
1. auf debian.org die pdf-Datei refcard angesehen
(mupdf als pdf viewer, in iceweasel von mir vorgegeben)
2. dann die pdf-Datei refcard.pdf heruntergeladen.

Nach dem Rechnerneustart Bleachbit ausgeführt.
Es war ein neues Verzeichnis .local/share/home/G vorhanden und 4 Dateien im Verzeichnis:
home
home-34563a2bf.log
root
root-279bf79e.log

Hier die hexdumps der Dateien, da es keine normale Textdateien sind

hexdump -e '8/1 "%02X ""\t"" "' -e '8/1 "%c""\n"' .local/share/G/home
DA 1A 6D 65 74 61 01 00 meta
00 00 00 00 37 04 B2 BF 7
00 00 00 24 00 00 00 20 $
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 34 4
00 00 00 00 00 00 00 00
00 00 00 00 2F 00 00 00 /

hexdump -e '8/1 "%02X ""\t"" "' -e '8/1 "%c""\n"' .local/share/G/home-3704b2bf.log
DA 1A 6A 6F 75 72 01 00
37 04 B2 BF 00 00 80 00
00 00 00 01 00 00 00 68
2F 64 11 89 00 00 00 00
56 2F A3 A6 00 2F 44 6F /Do
77 6E 6C 6F 61 64 73 2F wnloads/
72 65 66 63 61 72 64 00 refcard
64 6F 77 6E 6C 6F 61 64 download
2D 75 72 69 00 68 74 74 -urihtt
70 73 3A 2F 2F 77 77 77 ps://www
2E 64 65 62 69 61 6E 2E .debian.
6F 72 67 2F 64 6F 63 2F org/doc/
6D 61 6E 75 61 6C 73 2F manuals/
72 65 66 63 61 72 64 2F refcard/
72 65 66 63 61 72 64 00 refcard
00 00 00 68 00 00 00 00 h
00 00 00 00 00 00 00 00

hexdump -e '8/1 "%02X ""\t"" "' -e '8/1 "%c""\n"' .local/share/G/root
DA 1A 6D 65 74 61 01 00 meta
00 00 00 00 27 9B F7 9E '
00 00 00 24 00 00 00 20 $
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 34 4
00 00 00 00 00 00 00 00
00 00 00 00 2F 00 00 00 /

hexdump -e '8/1 "%02X ""\t"" "' -e '8/1 "%c""\n"' .local/share/G/root-279bf79e.log
DA 1A 6A 6F 75 72 01 00 jour
27 9B F7 9E 00 00 80 00 '
00 00 00 01 00 00 00 64 d
3F FE 1F E8 00 00 00 00 ?
56 2F A3 93 00 2F 74 6D V/ /tm
70 2F 72 65 66 63 61 72 p/refcar
64 00 64 6F 77 6E 6C 6F ddownlo
61 64 2D 75 72 69 00 68 ad-urih
74 74 70 73 3A 2F 2F 77 ttps://w
77 77 2E 64 65 62 69 61 ww.debia
6E 2E 6F 72 67 2F 64 6F n.org/do
63 2F 6D 61 6E 75 61 6C c/manual
73 2F 72 65 66 63 61 72 s/refcar
64 2F 72 65 66 63 61 72 d/refcar
64 00 00 00 00 00 00 64 dd
00 00 00 00 00 00 00 00
*

Nächster Versuch:
Neustart,
Kontrolle auf Veränderungen in .local/share/home/ nix drin.
iceweasel gestartet und auf debian.org die pdf-Datei refcard wieder angesehen
(mupdf als pdf viewer, in iceweasel von mir vorgegeben)

Nach dem Rechnerneustart kein Bleachbit ausgeführt sondern erst
Kontrolle .local/share/home/ nix drin.
Dann Blechbit ausgeführt und siehe da
ein neues Verzeichnis .local/share/home/n vorhanden und 2 Dateien im Verzeichnis:
root
root-279bf79e.log

Der Inhalt der beiden Dateien ist ähnlich, wie oben schon gezeigt.
Jetzt die Frage macht Blechbit den Salat oder mischt ein anderes Programm im Hintergrund mit?

@pferdefreund
@ MSfree
die Schwierigkeit ist ja dass ich vorher nie weiß, wie das neuerstellte Verzeichnis heist, so weiß ich nicht wie ich die beiden tools einseztzen kann. (die manpages erschlagen mich und ich fühle mich ein bisschen überfordert.)

Kleiner Tipp wäre hilfreich

[pferdefreund]

Sorry, was inotify angeht kenne ich das nur insoweit, dass ich weiß, das es das gibt. Wie es angewendet wird, da müsste ich auch erst RTFM machen.

[MSfree]

die Schwierigkeit ist ja dass ich vorher nie weiß, wie das neuerstellte Verzeichnis heist, so weiß ich nicht wie ich die beiden tools einseztzen kann.

lsof (list open files) gibt alle Dateien aus, die von irgendeinem Programm geöffnet sind. Die Liste kann daher ziemlich lang werden. Mit grep kann man Datenströme nach Zeichenketten durchsuchen. Da die Dateien ja wohl im home-Verzeichnis des angemeldeten Benutzers angelegt werden, kannst du auch einfach nach dem Benutzernamen filtern:

lsof | grep NameDerAngemeldetenBenutzers

[pferdefreund]

Wobei das mit dem lsof allerdings auch nur zieht, wenn die Anwendung die Datei auch gerade zum lsof-Befehl offen hat. Ordentliche Programmierer öffnen eine Datei nur dann, wenn sie wirklich gebraucht wird und schließen die dann auch gleich wieder, es sei denn der Zugriff wird öfter benötgt was bei der Datenmenge und Inhalt vermutlich nicht der Fall ist. Eventuell mal den bleachbit, was der auch immer ist, in einem Hexeditor öffnen und dort nachschauen, ob irgendwas mit .local/share... zu finden ist - wäre schon mal ein Anhaltspunkt.

[Radfahrer]

Ist bleachbit nicht irgend so ein Programm, dass den "Hausmeister" spielt und im Dateisystem herumfuhrwerkt?
Das Ding hätte ich auch im Verdacht.

[inne]

Kleiner Tipp wäre hilfreich

Die Logs erinnern stark an GVFS,

Code: Alles auswählen

~$ ls .local/share/gvfs-metadata/
./  ../  home  home-e375b4a4.log  root  root-8d0d755c.log

[uname]

Ich habe mal den Quellcode von bleachbit etwas durchsucht. Ich konnte aber nichts finden. Aber vielleicht einfach mal deinstallieren und schauen was dann passiert. Eigentlich ist eher die Frage was mit der Refcard damit zu tun hat [1]. Welche Anwendung könnte es nutzen bzw. hast du es irgendwann mal wissentlich genutzt? Oder vielleicht irgendein Script?

[1] https://www.debian.org/doc/manuals/refcard/refcard

Die Logs erinnern stark an GVFS,

Könntest du auch mal deaktivieren bzw. schauen ob es überhaupt genutzt wird.

[hoppla]

Hallo,
@inne
Korrekt!

Ich hatte ein bisschen gegooglt und noch ein bisschen rumprobiert:
Eine PDF-Date ohne Internet zu öffnen erzeugt keine Metadaten, jedoch sobalt man im Internet eine PDF-Datei online sich ansieht oder herunterläd, wird ein Verzeichnis /.local/share/gvfs-metadata angelegt und mit den home-, root-Dateien gefüllt.
Dort stehen wie beschrieben das Nutzerverhalten drin.
ich hatte auch im Bleachbit dieses /.local/share/gvfs-metadata unter Benutzerdefiniert zum Löschen aktiviert (hatte ich vergessen zu erwähnen).
Ich denke der gvfs-metadata-Daemon wird darauf hin versuchen die Metadaten wieder herzustellen und das anfangs beschriebene Verhalten auslösen.

So, da das nun wohl klar ist: wie kann ich nun doch automatiersiert das verhindern? Gibt es Einstellungen für den daemon abwürgen?