|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
Von Anonymer Feigling am Thursday 21. December 2006, 22:53 MEW (#1)
|
|
|
|
|
Eine nette Sache für eine Informatiker LAP. Erzeuge eine Datei so gross wie die Disk, lösche sie dann, aber lasse sie von einem Hintergrundprozess offen halten.
Lasse den Lehrling den Fehler suchen ;)
Wenn er ihn findet, lasse ihn studieren.
Wenn er die Kiste einfach neustartet, dann feststellt das das Problem weg ist, lasse ihn Sysadmin machen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
na, mach mal keine Witze ... hatte mal nen prozess der syslog gespammt hat, dass die platte voll war ... log gelöscht, ändert nichts ...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, wenn die Programme nicht von alleine crashen, dann muss man sie spätestens dann neustarten wenn man das Filesystem aufräumen will.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-> Volume Shadow Copy
Praktisch alle Windows Backup Tools arbeiten damit, damit lassen sich auch gesperrte Files kopieren (auch gleich das ganze volume, inkl. der system partition) ...
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, und auch unter Linux brauchst du FS Snapshots wenn du ein konsistentes Backup haben willst...
Wobei ich mit VSS auch schon so meine Probleme hatte.
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein. Du kannst das Filesystem unmounten.
Fuer den laufenden Betrieb: nur dann, wenn Du die Applikation nicht beenden/stoppen kannst resp. sie keine eingebaute Snapshot-Moeglichkeit/Export hat
(Datenbanken haben dies).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nein, das will man nicht. Siehe VMS.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 22. December 2006, 02:02 MEW (#4)
|
|
|
|
|
Für das eine braucht man root oder zumindest gewisse Privilegien, für das andere nicht - zumindest nicht für eigene Prozesse. Dass /proc eine tolle Idee ist bezweifle ich irgendwie. Immerhin gelangen so auch ungebetene Gäste ziemlich leicht und systemunabhängig an potentiell schützenswerte Daten oder werden setguid-Prozesse gesondert behandelt?
|
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 22. December 2006, 07:41 MEW (#6)
|
|
|
|
|
Nee, set-uid Binaries gehören nicht zwingend jemand anderem und set-gid Binaries sowieso nicht. Dokumentierte Nebeneffekte des s-bits sind auch, dass niemand auf solche Prozesse per ptrace oder Debugger zugreifen kann außer root (eventuell). An einen "file descriptor" kommt man außer durch obige genannte Methoden von außen auch normalerweise nicht heran. Deshalb ist so ein s-bit auch eine feine Methode Daten zu verstecken, denn obwohl sie scheinbar auslesbar sind, sind sie letztlich geschützt, sogar vor dem Benutzer selbst. Das set-gid-bit reicht da schon und ist bei weitem nicht so problematisch wie ein set-uid-bit.
Aber wenn SupaMegaHacka allmächtig ist, dann können wir uns natürlich auch einfach alle erschießen.
|
|
|
|
|
|
|
|
|
|
|
|
|
Suns kennen das /proc-Filesystem.
|
|
|
|
|
|
|
|
|
|
|
|
|
Das beschriebene Verhalten (unlink mit Filenamen, von denen noch offene Filehandles auf [logischerweise laufenden] Prozessen vorhanden sind), ist sauber designte Unix-Semantik seit Anfang an und allgemeinst bekannt (insbesondere ist es eine beliebte Frage an Unix-(Sysadmin-)Kursen, wieso /var/log immer noch voll sei, wo man doch syslog.* geloescht habe, nachdem /var/log voll lief).
Der Grund dafuer ist, dass unlink ein Reference-Counting macht.
Das undeleten von Files unter Unix|Linux ist filesystemabhaengig und geht von trivial (FAT) bis unmoeglich (allg. Filesysteme, die geloeschte Bloecke ausnullen, typischerweise Journalling-Filesysteme, aber nicht nur). ext2 loescht "nur" die Verweise auf die i-Nodes, was das Recovern trotzdem nicht leicht macht (indirekte Blocks).
Generell ist es eine schlechte Idee ein Undelete zu wollen. Dafuer gibt es Backups.
Abgesehen davon, sollte ein "Save As" aus der Applikation denselben Effekt, filesystem und plattformunabhaengig haben.
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 22. December 2006, 20:31 MEW (#19)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ja, sowas habe ich scon vor einigen Jahren gemacht - müssen, da ein rm voreilig war aber ein Programm die Datei noch offen hatte. Das ging da aber über /proc direkt.
--
ok> boot net - install
|
|
|
|
|
