Shred: Non funziona su Journaled FS?

Question

documentazione Shred dice brandello "non è garantito per essere efficace" (vedi in basso). Quindi, se io straccio di un documento sul mio file system Ext3 o su un Raid, che cosa succede? Ho Shred parte del file? Lo fa a volte tagliuzzare il tutto ea volte no? Può distruggere altre cose? Fa solo brandello l'intestazione del file?

  

ATTENZIONE: Si noti che shred si basa su un presupposto molto importante:   che il sistema di file sovrascrive i dati sul posto. Questo è il   tradizionale modo di fare le cose, ma molti disegni moderni file system   non soddisfano questa ipotesi. I seguenti sono esempi di file di   sistemi su cui straccio non è efficace, o non è garantito essere   efficace nei modi TEM tutti i file SYS:

     

  

• strutturato a log file system o journal, come ad esempio quelli forniti con AIX e Solaris (e JFS, ReiserFS, XFS, ext3, ecc.)

  

• file system che scrivono dati ridondanti e portano avanti anche se alcune scritture falliscono, come ad esempio i file system RAID basati su

  

• file system che fanno istantanee, come il server NFS di Network Appliance

  

• file system cache in sedi temporanee, come ad esempio la versione NFS 3 clienti

  

• file compresso sistemi

  

     

Nel caso di file system ext3, la dichiarazione di non responsabilità di cui sopra si applica   (E straccio è quindi di limitata efficacia) solo in data = journal   modalità, i periodici dati dei file in aggiunta al solo metadati. Nel   entrambi i data = ordered (predefinito) e modalità data = writeback, rompere   funziona come al solito. modalità journaling ext3 possono essere modificati aggiungendo   i dati = qualcosa di opzione per le opzioni di montaggio per un   particolare sistema di file nel file / etc / fstab, come documentato nel   pagina man mount (man mount).

Answer 1

Tutto straccio fa è sovrascrivere, a filo, controllare il successo, e ripetere. E non fa assolutamente nulla per scoprire se sovrascrivere un file si traduce in realtà i blocchi che contenevano i dati originali vengano sovrascritti. Questo perché senza sapere le cose non standard per il file system di fondo, non si può.

Quindi, filesystem journaling non sovrascrivere i blocchi originali in luogo, perché sarebbe impedire loro recupero in modo pulito da errori in cui il cambiamento è a metà-scritto. Se i dati vengono journal, quindi ogni passaggio di straccio potrebbe essere scritta in una nuova posizione sul disco, in questo caso nulla è tagliuzzato.

filesystem RAID (a seconda della modalità RAID) potrebbero non sovrascrivere tutte le copie dei blocchi originali. Se c'è la ridondanza, si potrebbe distruggere un disco, ma non l'altro (s), o si potrebbe trovare che i diversi passaggi hanno colpito diversi dischi in modo tale che ogni disco è in parte tagliuzzato.

Su qualsiasi file system, l'hardware del disco stesso potrebbe così accadere per rilevare un errore (o, nel caso di flash, applicare usura livellamento anche senza un errore) e riassociare il blocco logico ad un blocco fisico diverso, tale che l'originale è marcato difettosa (o nuovo), ma mai sovrascritto.

file system compressi potrebbero non sovrascrivere i blocchi originali, perché i dati con cui sovrascrive rompere è o casuale o estremamente comprimibile ad ogni passaggio, ed entrambi si potrebbe causare il file per cambiare radicalmente la dimensione compressa e quindi essere trasferito. NTFS memorizza piccoli file nella MFT, e quando distruggere giri fino la dimensione del file a un multiplo di un blocco, il suo primo "sovrascrivere" causera 'il file di essere trasferito fuori in una nuova posizione, che sarà poi inutilmente triturati lasciando il piccolo fessura MFT intatta.

Shred non è in grado di rilevare qualsiasi di queste condizioni (a meno che non si dispone di una speciale implementazione che affronta direttamente i vostri fs e autista blocca - non so se effettivamente esistono tali cose). Ecco perché è più affidabile quando utilizzato su un disco intero che su un filesystem.

Shred mai brandelli "altra roba", nel senso di altri file. In alcuni dei casi sopra brandelli blocchi precedentemente allocati al posto dei blocchi che contengono i dati. Inoltre non tagliuzzare tutti i metadati nel file system (che credo sia quello che si intende per "intestazione del file"). L'opzione -u fa tentativo di sovrascrivere il nome del file, rinominando con un nuovo nome della stessa lunghezza e quindi accorciando che un carattere alla volta fino a 1 char, prima di eliminare il file. È possibile vedere in azione se si specifica -v troppo.

Answer 2

Le altre risposte hanno già fatto un buon lavoro di spiegare il motivo per distruggere non può essere in grado di fare il suo lavoro correttamente.

Questo può essere riassunta come:

tagliuzzare funziona solo su partizioni, non i singoli file

Come spiegato nelle altre risposte, se a distruggere un singolo file:

• non v'è alcuna garanzia che il dato effettivo è davvero sovrascritto, in quanto il file system può inviare scrive lo stesso file in diverse posizioni sul disco
• non v'è alcuna garanzia che il fs non creano copie dei dati altrove
• le fs potrebbe anche decidere di "ottimizzare la via" le vostre scrive, perché si sta scrivendo lo stesso file più volte (la sincronizzazione è supposto per evitare questo, ma ancora una volta: nessuna garanzia)

Ma anche se si sa che tuo filesystem non fa nessuna delle cose brutte di cui sopra, si deve anche considerare che molte applicazioni creano automaticamente copie di dati del file:

• file di ripristino incidente che word processor, editor (come vim) ecc scriveranno periodicamente
• file miniatura / anteprima di file manager (a volte anche per i non-imagefiles)
• i file temporanei che molte applicazioni utilizzano

Quindi, a meno di controllare ogni singolo binario che si utilizza per lavorare con i tuoi dati, potrebbe essere stato copiato destra, sinistra e centro senza di voi saperlo. L'unico modo realistico è quello di sempre brandello partizioni complete (o dischi).

Answer 3

La preoccupazione è che potrebbero esistere i dati su più di un posto sul disco. Quando esiste il dato esattamente una posizione, quindi triturare può deterministicamente "cancellare" quelle informazioni. Tuttavia, i file system che giornale o altri file system avanzati possono scrivere i dati del tuo file in più posizioni, momentaneamente, sul disco. Shred - dopo il fatto - non ha alcun modo di sapere su questo e non ha alcun modo di sapere dove i dati potrebbero essere stati scritti temporanea su disco. Così, non ha modo di cancellare o sovrascrivere i settori del disco.

Immaginate questo: Si scrive un file su disco in un file system journal che non journal solo i metadati, ma anche i dati del file. I dati del file viene scritto temporaneamente al giornale, e poi scritto nella sua posizione finale. Ora si utilizza distruggere sul file. La posizione finale in cui i dati sono stati scritti può essere tranquillamente sovrascritto con straccio. Tuttavia, sminuzzare avrebbe dovuto avere un modo di garantire che i settori sulla rivista che conteneva temporaneamente il contenuto del file vengono sovrascritti anche essere in grado di promettere che il file non è veramente recuperabile. Immaginate un file di sistema in cui il giornale non è nemmeno in una posizione fissa o di una lunghezza fissa.

Se si utilizza straccio, allora si sta cercando di garantire che non v'è alcun modo possibile i vostri dati potrebbero essere ricostruiti. Gli autori di straccio sono onesti che ci sono alcune condizioni al di fuori del loro controllo in cui non possono fare questa garanzia.