Bei ASCII Text kannst du mit einem normalen Hexeditor noch nach Einträgen in deinem Dumpfile suchen und sind somit leicht zu finden. Bei Binärdaten können die Informationen zwar auch noch vorhanden sein, aber diese zu finden, das dürfte das wesentliche Problem sein.
Bei Binärdaten kann man nach den Header-Informationen und der Dateistruktur suchen. Wird z.B. bei JPG Dateien genauso gemacht.
Aber abgesehen davon bringt das sowieso nichts. Wenn jemand mutwillig die Logs löscht, dann helfen auch die Hälfte der Logs nicht, denn woher will man wissen, dass die Logs nicht manipuliert sind? Oder auf Grund des Dateisystems gerade die Teile fehlen, die wichtig sind?
Achja? Systemd definiert sein Binärformat ausdrücklich nicht und warnt dafür darauf zu bauen. Man solle lieber die eigenen Tools nutzen. Und ob die Löschung/Manipulation unentdeckt bleibt, hängt von der Signierung ab. Es gibt Syslog die das auch schon vor Systemd getan haben, ist also kein wirkliche neues Feature.
Das Einzige, was in die Richtung geht ist die Aussage: "Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right."
Wird aber gleich wieder etwas entschärft mit: "That said we'll of course try hard to keep this document up-to-date and accurate."
Die Informationen würden jedenfalls reichen um die Dateien, soweit noch rekonstruierbar, aufzufinden und wiederherzustellen. Mal ganz abgesehen davon, dass das auch mit Dateien gemacht wird, deren Struktur nur per Reverse Engineering bekannt ist (z.B. RAW Dateien).
Man solle lieber die eigenen Tools nutzen.
Jein, das stimmt so nicht. Die eigentliche Aussage ist: "Instead of implementing your own reader or writer for journal files we ask you to use the Journal's native C API to access these files. It provides you with full access to the files, and will not withhold any data. If you find a limitation, please ping us and we might add some additional interfaces for you." Das ist aber ganz normal und logisch. Gehört meiner Meinung nach auch zu einem ordentlichen Logging-Dienst dazu, d.h. sowohl das Schreiben der Logdaten, als auch den Zugriff auf diese zu unterstützen. Egal, ob die Logdaten nun als ASCII Text gespeichert werden oder in einem anderen Format. Ist auch genau das was mir bei syslog-ng/rsyslog immer gefehlt hat, ein Programm, welches den Zugriff auf die Logdaten brauchbar gestaltet. Gäbe es sowas wie journalctl für diese, wäre ich ein Stück weit zufriedener gewesen. Mit grep & Co im Log rumwurschteln fand ich immer sehr halbgar.
Und ob die Löschung/Manipulation unentdeckt bleibt, hängt von der Signierung ab. Es gibt Syslog die das auch schon vor Systemd getan haben, ist also kein wirkliche neues Feature.
Das stimmt. Genutzt wurde es aber selten und schon gar nicht per Default.
Ist ein bisschen wie mit der Datei .xsession-errors. Inzwischen loggen ja immer mehr Programme ins Journal (soweit verfügbar) und nicht mehr in besagte Datei. Das ist wirklich ein Segen, denn die .xsession-errors war echt ein furchtbares Chaos. Prinzipiell hätte man das auch früher schon machen können. Hat in der Realität aber praktisch niemand gemacht. Zum Glück hat das Journal aber dazu geführt, dass (optional, soweit verfügbar) da ein Umdenken stattgefunden hat.
Bei ASCII Text kannst du mit einem normalen Hexeditor noch nach Einträgen in deinem Dumpfile suchen und sind somit leicht zu finden.
Bei Binärdaten können die Informationen zwar auch noch vorhanden sein, aber diese zu finden, das dürfte das wesentliche Problem sein.
Bei Binärdaten kann man nach den Header-Informationen und der Dateistruktur suchen. Wird z.B. bei JPG Dateien genauso gemacht.
Aber abgesehen davon bringt das sowieso nichts. Wenn jemand mutwillig die Logs löscht, dann helfen auch die Hälfte der Logs nicht, denn woher will man wissen, dass die Logs nicht manipuliert sind?
Oder auf Grund des Dateisystems gerade die Teile fehlen, die wichtig sind?
Ne, das finde ich nicht überzeugend.
Achja? Systemd definiert sein Binärformat ausdrücklich nicht und warnt dafür darauf zu bauen. Man solle lieber die eigenen Tools nutzen.
Und ob die Löschung/Manipulation unentdeckt bleibt, hängt von der Signierung ab. Es gibt Syslog die das auch schon vor Systemd getan haben, ist also kein wirkliche neues Feature.
Das Einzige, was in die Richtung geht ist die Aussage:
"Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right."
Wird aber gleich wieder etwas entschärft mit:
"That said we'll of course try hard to keep this document up-to-date and accurate."
Die Informationen würden jedenfalls reichen um die Dateien, soweit noch rekonstruierbar, aufzufinden und wiederherzustellen. Mal ganz abgesehen davon, dass das auch mit Dateien gemacht wird, deren Struktur nur per Reverse Engineering bekannt ist (z.B. RAW Dateien).
Jein, das stimmt so nicht. Die eigentliche Aussage ist:"Instead of implementing your own reader or writer for journal files we ask you to use the Journal's native C API to access these files. It provides you with full access to the files, and will not withhold any data. If you find a limitation, please ping us and we might add some additional interfaces for you."
Das ist aber ganz normal und logisch. Gehört meiner Meinung nach auch zu einem ordentlichen Logging-Dienst dazu, d.h. sowohl das Schreiben der Logdaten, als auch den Zugriff auf diese zu unterstützen. Egal, ob die Logdaten nun als ASCII Text gespeichert werden oder in einem anderen Format.
Ist auch genau das was mir bei syslog-ng/rsyslog immer gefehlt hat, ein Programm, welches den Zugriff auf die Logdaten brauchbar gestaltet. Gäbe es sowas wie journalctl für diese, wäre ich ein Stück weit zufriedener gewesen. Mit grep & Co im Log rumwurschteln fand ich immer sehr halbgar.Das stimmt. Genutzt wurde es aber selten und schon gar nicht per Default.
Ist ein bisschen wie mit der Datei .xsession-errors. Inzwischen loggen ja immer mehr Programme ins Journal (soweit verfügbar) und nicht mehr in besagte Datei. Das ist wirklich ein Segen, denn die .xsession-errors war echt ein furchtbares Chaos.
Prinzipiell hätte man das auch früher schon machen können. Hat in der Realität aber praktisch niemand gemacht. Zum Glück hat das Journal aber dazu geführt, dass (optional, soweit verfügbar) da ein Umdenken stattgefunden hat.
Nicht jein sondern ja, nur Deppen die ständig ihren Code nachziehen wollen, implementieren das selbst.[1]
http://www.freedesktop.org/wiki/Software/systemd/journal-files/