Comment est-ce que je déchire récursivement toute une arborescence de directorys?

J'ai un tree de directory que je voudrais déchiqueter avec l'utilitaire 'shred' de Linux. Malheureusement, shred n'a pas d'option -R pour le déchiquetage récursif.

Comment puis-je déchiqueter récursivement un tree de directorys entier?

Utilisez la command find pour exécuter le shred récursivement:

 find <dir> -type f -exec shred {} \; 

Méfiez-vous de déchiqueter!

De la page de manuel shred:

ATTENTION: Notez que shred repose sur une hypothèse très importante: le système de files écrase datatables en place. C'est la façon traditionnelle de faire les choses, mais de nombreuses designs de filesystems modernes ne satisfont pas cette hypothèse. Voici des exemples de filesystems sur lesquels shred n'est pas efficace ou n'est pas garanti pour tous les modes de système de files:

  • les filesystems structurés ou journalisés, tels que ceux fournis avec AIX et Solaris (et JFS, ReiserFS, XFS, Ext3, etc.)

  • les filesystems qui écrivent des données redondantes et continuent même si certaines écritures échouent, comme les filesystems RAID

  • les filesystems faisant des instantanés, tels que le server NFS de Network Appliance

  • les filesystems qui mettent en cache dans des locations temporaires, tels que les clients NFS version 3

  • filesystems compressés

Dans le cas des filesystems ext3, la clause de non-responsabilité ci-dessus s'applique (et le déchiquetage n'a donc qu'une efficacité limitée) uniquement dans le mode journal = journal, qui journalise datatables en plus des métadonnées. Dans les deux modes data = ordered (default) et data = writeback, shred fonctionne comme d'habitude. Les modes de journalisation Ext3 peuvent être modifiés en ajoutant l'option data = something aux options de assembly d'un système de files particulier dans le file / etc / fstab, comme indiqué dans la page man de assembly.

De plus, les sauvegardes du système de files et les miroirs distants peuvent contenir des copys du file qui ne peuvent pas être supprimées, ce qui permettra de récupérer ultérieurement un file déchiqueté.

Solution: utilisez un système de files crypté, et supprimez simplement vos files.

En combinant cette réponse avec les options les plus connues pour déchiqueter en utilisant ce lien de débordement de stack ' Suppression définitive et sécurisée des files sur CentOS ':

 find <directory> -depth -type f -exec shred -v -n 1 -z -u {} \; 

Edit: Sachez que la meilleure réponse pour déchiqueter un seul file force une synchronisation qui écrit les modifications apscopes au support avant de supprimer le file car certains ou tous les filesystems journalisés ont un tampon.

Si possible, la command find devrait appeler un script shell sur le file qui s'exécute:

 shred -v -n 1 /path/to/your/file #overwriting with random data sync #forcing a sync of the buffers to the disk shred -v -n 0 -z -u /path/to/your/file #overwriting with zeroes and remove the file 

sur chaque file.

 find /your/directory -exec shred {} \; 

Utilisez plutôt la suppression sécurisée.

 sudo apt-get install secure-delete srm -r pathname 

Terminé. La suppression sécurisée est beaucoup plus paranoïaque que déchiquetée, en utilisant 38 passes au lieu de 3. Pour faire une seule passe rapide, utilisez

 srm -rfll pathname 

fll vous obtient un générateur de données randoms less random, et seulement un seul passage.

 find [dirname] -depth -type f -exec shred -n1 {} \; 

Ceci effectue une search en profondeur des files dans le directory [dirname], puis exécute la command shred -n1 sur chaque file. Lorsque vous supprimez des files et / ou des directorys, l'ajout de la valeur par défaut est une bonne habitude, même si ce n'est pas ssortingctement nécessaire pour ce cas. Lors de l'exécution de ce type de command avec rm -rf au lieu de shred , -depth est nécessaire pour s'assurer que les directorys ne sont pas supprimés avant que le contenu des directorys soit supprimé (ce qui provoque des erreurs).