JoeToe

updatedb und der Verlust der Geheimhaltung

updatedb stellt dem Nutzer die Möglichkeit bereit schnell und Resourcenschoned nach Dateien zu suchen. Dies natürlich auf dem eigenen Rechner. Wenn man so will “ein kleines Google auf dem eigenen Rechner”.

wurde die Festplatte einmal mit “updatedb” oder “updatedb.mlocate” eingelsen, so wird ein Index erstellt, der eben das optimierte Suchen ermöglicht. Dies’ lässt sich dann wiederum mit dem Befehl “locate” veranlasst.

BrainDB wäre nicht BrainDB, wenn es da nicht auch einen Haken gäbe! ;-)

Das Problem besteht nämlich in der Tatsache, das fast das alle eingehängten Datenträger in diesem Index landen. Das bedeutet aber auch, dass z.B. verchlüsselte Datenträger in diesem Index auftauchen. Das dies’ nicht im Sinne der Verschlüsselung ist, kann sich sicher jeder spontan klar machen.

Nun - Was kann man dagegen machen? Bei FreeBSD wird beispielsweise ein Warnhinweis ausgegeben, wenn man “updatedb” starten will, bei Linux (in diesem Falle Debian) ist dies nicht so. dort wird das automatische einlesen des Dateisystems periodisch (bzw. beim Start) im Hintergrund ausgeführt.
Gut an diesem Automatismus ist, dass sich über die zentrale Konfiguration einstellen lässt, was indiziert werden doll.

vi /etc/updatedb.conf
PRUNE_BIND_MOUNTS=”yes”
# PRUNENAMES=”.git .bzr .hg .svn”
PRUNEPATHS=”/tmp /var/spool /media /home /mnt /data”
PRUNEFS=”NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf”

Für unseren Fall ist vor allem “PRUNEPATHS” interessant. Wie du siest, habe ich “/mnt”, “/home” und “/data” hinzugefügt. Nun findet man zwar keine persönlichen Daten mehr, aber ich denke, dass das genau das ist, was ich will.

Schlagworte: , , , ,

Kommentieren