ubuntuusers.de

Hallo,

ich bin neu bei Linux und schreibe gerade an einem Forensik-Tool im Terminal, welches ich eigentlich bereits unter Windows begonnen hatte.

Momentan steht die Frage im Raum, wohin solche Programme unter Linux grundsätzlich Dateien ablegen sollten bzw. können. Das Tool ermöglicht die Extraktion von Schlupfspeicher und auch Datein aus einem Disk-Image heraus. Außerdem können auch gelöschte Dateien - solange noch nicht überschrieben - wiederhergestellt werden.

Sollte man für sowas den persönlichen Ordner des Benutzers /home/USERNAME verwenden, oder gibt es dafür ein allgemeines Verzeichnis unter Linux? Wie sieht es mit dem Ordner /opt aus, irgendwo habe ich gelesen, dass der für Programme von Drittanbietern gedacht ist. Bei mir hat da aber nur Google Earth etwas abgelegt, obwohl ich schon einiges nachinstalliert habe.

Vielleicht könnte ein erfahrener Linux-Nutzer mich hier etwwas aufklären.

Wurde dir doch breits beantwortet → 9506107

Also wozu nun noch ein Thread?

Bemerkenswert ist die Tatsache, daß er nicht nur keine Linux-Basics hat, aber ein Linux-Programm schreiben will. Nicht zu reden von seinen merkwürdigen Vorstellungen über OSS ("auch einfach dem Poster Glauben schenken" ist der Hit, irgendwie erinnert er mich an unseren iPad-Freund der letzten Wochen) und das gerade bei einem solchen Tool. Fragt sich auch, was Beta-/Alphatester eigentlich testen sollen. Sowas macht man in einer VM - wie soll man denn da vorgehen, absichtlich was schrotten? Für sein Closed-Source-Zeug, pff.

sceptical schrieb:

die Extraktion von Schlupfspeicher

von *was* bitte?

Außerdem können auch gelöschte Dateien - solange noch nicht überschrieben - wiederhergestellt werden.

Ja, das können sie. Gilt systemunabhängig.

Sollte man für sowas den persönlichen Ordner des Benutzers /home/USERNAME verwenden, oder gibt es dafür ein allgemeines Verzeichnis unter Linux?

/home/$USER/Unterverzeichnis_nach_Wunsch passt.

Wie sieht es mit dem Ordner /opt aus, irgendwo habe ich gelesen, dass der für Programme von Drittanbietern gedacht ist.

Richtig, für Programme. Nicht für Nutzerdaten.

Momentan steht die Frage im Raum, wohin solche Programme unter Linux grundsätzlich Dateien ablegen sollten bzw. können.

Sollte man für sowas den persönlichen Ordner des Benutzers /home/USERNAME verwenden, oder gibt es dafür ein allgemeines Verzeichnis unter Linux?

Es gibt dafür kein vorgesehenes Verzeichnis! Und für "Forensik" ist normalerweise der Administrator zuständig.

Aber davon abgesehen finde ich die Klassifizierung als "Forensik-Tool" etwas hoch gegriffen. Hat eher etwas mit einfachem "reversed engeniering" zu tun. Wobei ich da die Dateistruktur für exFat vermisse (exFat könnte für mich möglicherweise interessant werden, wegen der erweiternden Zeitstempel).

Nochmal: wenn du dein Programm in ein Linux System einbringen willst, gehört es nach /usr/local/bin/. Dateien, die die Anwendung erzeugt, gehören normalerweise in das Home Verzeichnis des Programm Starters (was bei administriativen Aufgaben möglicherweise anders erwünscht ist).

Schau dir doch mal an, wie etablierte Tools wie TestDisk das handhabt.

@timothy2068: „Schlupfspeicher“ ist im englischen „slack space“. Der Teil im letzten Datenblock von Dateien, der nicht mehr zur Datei gehört, weil Dateigrössen in der Regel nicht einem Vielfachen der Blockgrösse entsprechen. Da können manchmal interessante Daten stecken, entweder per ”Zufall” oder auch absichtlich.

Hier ist beispielsweise eine Beschreibung was sich auf der IBM DOS V1.00 Diskette finden lässt: https://daniel.sedory.com/DOS/ibm100/Slack.htm

Alles klar, den deutschen Begriff kannte ich nur noch nicht.

Alles, was $USER an Daten erzeugt, gehört unter /home/$USER. Nicht unter /opt und auch nicht sonstwohin.

Wobei ein brauchbares Programm natürlich keine hart kodierten Verzeichnisse verwendet, sondern den Benutzer angeben lässt wo Daten gespeichert werden.

Vielen Dank für die Antworten, das hilft auf jeden Fall weiter. Ja, das Programm landet jetzt unter /usr/local/bin. Das Problem hierbei ist, dass solche Tools wie auch Disk-Editoren in Hex-Editoren für den Zugriff direkt auf Disks bzw. block devices Admin-Rechte brauchen. Das Programm wird dann mit sudo ausgeführt werden müssen.

@von.wert Warum soll das Bemerkenswert sein. Ich will nicht, ich habe schon. Bis zum ersten Release 1.0 ist es nicht mehr weit. Ich bin kein Programmier-Neuling nur Neuling unter Linux.

@schwarzheit Hatte ich nicht gelesen bzw. gar keine Benachrichtigung erhalten?

sceptical schrieb:

@schwarzheit Hatte ich nicht gelesen

Genau das ist dein Problem.

@schwarzheit

Was?

sceptical schrieb:

[…] Forensik-Tool […] wohin solche Programme unter Linux grundsätzlich Dateien ablegen sollten bzw. können.

Bei einem solchen Tool ist wohl aufgrund seiner Aufgabe eine Installation überhaupt nicht sinnvoll bzw. sogar kontraproduktiv. Wenn so etwas auf einem zu untersuchenden Rechner überhaupt gestartet wird, dann wohl von einem externen Medium, z.B. einem Live-System. Da ist man dann völlig frei in der Organisation der Verzeichnisstruktur.

Wenn man dennoch eine reguläre Installation des Tools vornehmen will, sollte man wie für jedes Programm den "Filesystem Hierarchy Standard" (FHS) beachten, hierfür gibt Verzeichnisstruktur einen Eindruck und weiter führende Hinweise.

Wenn es als grafisches Programm unter einem Desktop laufen soll, ist die Beachtung der von https://freedesktop.org 🇬🇧 veröffentlichten Standards sinnvoll, insbesondere:
XDG Base Directory Specification 🇬🇧

sceptical schrieb:

Das Programm wird dann mit sudo ausgeführt werden müssen.

ls -lh /dev/nvme0n1
brw-rw---- 1 root disk 259, 0  1. Jun 06:53 /dev/nvme0n1

Es wird reichen wenn der User in der Gruppe "disk" ist.

Oder man operiert auf einer Imagedatei vom Datenträger oder der Partition statt auf dem Original. Dann braucht man keine speziellen Rechte mehr für das Werkzeug und auch eine reguläre Installation macht genau so viel Sinn wie bei anderen Programmen.

kB schrieb:

Bei einem solchen Tool ist wohl aufgrund seiner Aufgabe eine Installation überhaupt nicht sinnvoll bzw. sogar kontraproduktiv.

ACK.