Shred/rm supprimer un fichier + fichier cacher

Support Debian
#1

Bonjour à tous,
J’aimerais supprimer un fichier.

Man rm:
Notez que si vous utilisez « rm » pour détruire un fichier, il pourrait être possible de récupérer une partie du contenu de ce fichier, avec suffisamment de savoir-faire et de temps.
Si vous voulez réellement que son contenu soit irrécupérable, utilisez plutôt shred.

Man shred:
Shred - Écrire par dessus un fichier pour en camoufler le contenu, et optionnellement l’effacer.

Rm dit que les données supprimer sont récupérable alors va utiliser shred et shred dit qu’il écrit par dessus donc irrécupérable mais vu qu’il ré-écrit dessus il ne libère pas l’espace du disque dur ?

  • pour supprimer un fichier, le rendre irrécupérable et aussi libérer de l’espace du disque dur, quel genre de commande puis-je utiliser ?
  • avec rm, comment peut-on supprimer les fichiers cacher d’un dossier ? avec “rm -R dossier/.*” les fichiers caché sont bien supprimer mais sa me donne toujours une erreur pour “.” et “…”.
#2

Il aurait fallu lire le man en entier. :wink:

[quote=“man shred”]-u, --remove
tronquer et supprimer le fichier après l’avoir écrasé[/quote]_________________

Attention, ça ne te supprime pas QUE les fichiers cachés (ni QUE les fichiers d’ailleurs) :

$ mkdir -p test/.dir $ touch test/.dir/.file test/.dir/file $ rm -R test/.* rm: impossible de supprimer le répertoire : « test/. » rm: impossible de supprimer le répertoire : « test/.. » $ ls -lA test/ total 0
Si ton but est bien de ne supprimer que les fichiers cachés (pas les fichiers normaux ni aucun dossier) ma première idée serait d’utiliser find pour affiner les conditions.

#3

J’aurais aussi du lire les options de shred.
Mais encore un soucis, j’arrives pas à effacer les dossiers avec shred:

kripteks@home:~/tes$ mkdir test kripteks@home:~/tes$ shred -u test shred: test : échec d'ouverture en écriture: est un dossier kripteks@home:~/tes$ shred --remove test shred: test : échec d'ouverture en écriture: est un dossier kripteks@home:~/tes$ shred -f -u test shred: test : échec d'ouverture en écriture: est un dossier kripteks@home:~/tes$ shred -f --remove test shred: test : échec d'ouverture en écriture: est un dossier kripteks@home:~/tes$

édite: j’ai lu qu’il ne supprime que les fichiers, donc pas les dossiers, sur le doc d’ubuntu à propos de shred il propose “wipe” pour supprimer les dossiers.

Merci :wink:

#4

Salut,

wipe -r -i -Q 35 ~/chemin/dossier_à_effacer

L’idée : déplacé le ~/chemin/dossier_à_effacer sur une partition vide, puis shred.

# shred -fvz -n 30 /dev/sdx

non ? :033

#5

rm n’efface pas les fichiers. Il ne fait qu’un “unlink”, c’est-à-dire supprimer un lien (“hard link”, cf. man ln) entre l’entrée dans le répertoire et l’inode correspondant. Si c’était le dernier, alors l’inode et les blocs occupés sont libérés, mais pas effacés. Si ce n’était pas le dernier lien, alors le fichier reste en place et accessible par les autres liens.

Ouais, et notamment la section suivante (en anglais chez moi, désolé) :

CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. This is the traditional way to do things, but many modern file system designs do not satisfy this assumption. The following are examples of file systems on which shred is not effective, or is not guaranteed to be effective in all file sys- tem modes:
En bref : l’effacement n’est pas garanti. Pour effacer le contenu d’un fichier de façon sûre, il faudrait un outil qui travaille au niveau du système de fichiers. Et de toute façon, si le fichier a été modifié, il peut rester des traces de l’ancien contenu ailleurs sur le disque. Pour être à peu près sûr de tout effacer, il faut réécrire tout le volume (partition) contenant le système de fichiers.

#6

L’idée de déplacer sur partition vide et utiliser shred est une très bonne idée.
Je possède plusieurs centaine de gb vide sur une partition non utiliser.

Donc:

  • mv /home/kripteks/mondossier /dev/sda2
  • shred … /dev/sda2

Mais est-ce que mv déplace vraiment tous le contenu, aurais-je le dossier quelque part sur mon disque dur ? (comme rm par exemple)
Edite: on dirait que oui, donc utiliser le partitionnage chiffré comme lvm est déjà une bonne solution.

#7

mv peut être vu comme un enchaînement de cp+rm => les données d’origine ne sont pas “déplacées” :

  • cas particulier : si la source et la destination sont sur la même partition, seules les entrées de répertoires sont modifiées (ça va vachement plus vite)
  • si la source et la destination sont sur deux partitions différentes, alors c’est bel et bien un cp+rm

Bref, ce que tu dis ne change rien au problème, les données sont toujours présentes sur la partition d’origine après un mv.

#8

Perso, si je veux vraiment effacer le contenu d’un fichier, j’utilise la commande dd ( à utiliser en faisant très attention sinon gare ! )

soit par exemple à effacer

ls -lh test.sh -rw------- 1 toto toto 70K 21 janv. 15:15 test.sh
Hé bien je fais ceci :

dd if=/dev/zero of=test.sh bs=100k count=1 1+0 enregistrements lus 1+0 enregistrements écrits 102400 octets (102 kB) copiés, 0,00139466 s, 73,4 MB/s
j’ai écrit 100 kio de zero dans le fichier test.sh, il ne reste plus qu’à vérifier

ls -lh test.sh -rw------- 1 toto toto 100K 21 janv. 15:17 test.sh
et enfin

Ce fichier sera encore récupérable, certes, mais remplis de zéro. On peut aller loin avec dd ( loin dans la c*nnerie aussi, mef …)

#9

D’accord avec syam, ça n’a aucun intérêt pour effacer des fichiers de façon sûre.

Ben non, même problème que pour shred avec les systèmes de fichiers “modernes” : rien ne garantit que les zéros vont être écrits sur l’ancien emplacement du fichier.

#10

D’accord avec syam, ça n’a aucun intérêt pour effacer des fichiers de façon sûre.

Ben non, même problème que pour shred avec les systèmes de fichiers “modernes” : rien ne garantit que les zéros vont être écrits sur l’ancien emplacement du fichier.[/quote]
??? Je rêves ou quoi ? ils vont êtres écrits sur la Lune mes zéros ? ou dans mon fichier ? à mon avis ils vont être écrits dans mon fichier et pas sur la Lune !!!

#11

La notion de fichier est une abstration du système de fichiers. Au final, le contenu d’un fichier est écrit dans des blocs sur le disque, qui ne sont pas accessibles directement à l’utilisateur mais seulement par l’intermiédiaire du système de fichiers, qui gère comme ça lui chante la correspondance entre les blocs et les fichiers. Lorsqu’on remplace le contenu, rien ne garantit que les nouvelles données vont être écrites dans les mêmes blocs et donc que les données précédentes vont être écrasées. Le fait qu’elles ne soit plus accessibles en lisant le fichier ne signifie pas qu’elles ont disparu du disque.

On peut même envisager un système de fichiers que décide que quand on écrit une longue suite de zéros dans un fichier, il n’y a pas besoin d’allouer des blocs sur le disque : il suffit de dire qu’il y a n zéros. Je suis sûr que ça existe déjà.

#12

D’ailleurs il m’est arrivé d’avoir à effacer des fichiers contenant des infos perso, pour être sûr d’y parvenir, j’ai dans un premier temps “effacé” tous les fichiers perso avec un classique rm, puis j’ai entré cette commande :

puis j’ai attendu que Gros_fichier remplisse l’espace disponible, autant dire que le disque était remplis à 100 % , puis j’ai interrompu ma commande dd avec un simple Ctrl-C , puis

Tu crois sérieusement que sur ce coup là je n’ai pas tout effacé ?

#13

Moui … c’est un peu flou, tout ça, toujours est-il que dans mon post précédent je donne une méthode sûre pour effacer définitivement des fichiers, c’est du lourd, certes, mais c’est sûr que ça marche !

#14

La page de manuel de shred est assez édifiante, je trouve.

A condition de l’exécuter en tant que root ou sur un système de fichiers qui n’a pas d’espace réservé (5% par défaut sur ext2/3/4).
Et à condition qu’entre la suppression et l’écrasement, des blocs appartenant aux fichiers effacés n’aient pas été préalloués pour de nouveaux fichiers, comme le permet notamment ext4.

#15

La page de manuel de shred est assez édifiante, je trouve.[/quote]
Je reconnais ne l’avoir lu que très-très rapidement ! C’est sûr que j’ai beaucoup à apprendre là dessus ( s’il n’y avait que ça ! ) Et en + ça m’interresse …

[quote=“PascalHambourg”]

A condition de l’exécuter en tant que root ou sur un système de fichiers qui n’a pas d’espace réservé (5% par défaut sur ext2/3/4).[/quote]
Je ne me souviens plus si j’ai exécuté cette commande en tant que root ( je penses que oui )

L’espace réservé n’est pas destiné a recueillir des fichiers qu’on tenterai d’éliminer, il est destiné à la survie du système de fichier lui même

#16

Encore pire, ça dépend également du disque.

  • la plupart des disques “classiques” à plateau ont quelques blocs en réserve dans le cas où l’un des blocs du disque deviendrait défectueux (remplacement transparent pour l’OS) => des données peuvent rester sur lesdits blocs défectueux, devenus inaccessibles à l’OS mais pas à un MEB
  • les disques SSD ont un système de “wear-leveling” qui modifie en permanence la correspondance entre blocs physiques et ce que l’OS voit, pour augmenter la durée de vie du disque => quand l’OS donne l’ordre d’écrire 50 fois sur le même bloc, en réalité c’est probablement 50 blocs physiques différents qui vont être écrits
  • toujours concernant les disques SSD, ils ont également un système d’« over-provisioning » (blocs en réserve) un peu similaire à ce que j’ai décrit pour les disques à plateau, mais qui n’est pas limité à la “réparation de blocs” (ils sont aussi utilisés pour améliorer la performance) et dont le volume est beaucoup plus important : il y a parfois jusqu’à 30% de capacité supplémentaire “cachée”
  • bien entendu les disques hybrides plateau/SSD (où le SSD sert de cache rapide) ont tous ces problèmes à la fois.

Bref, pour un SSD il est quasiment impossible de s’assurer que des données ont été effacées. Et dans les deux cas (SSD et disques à plateau) le seul moyen d’être 100% sûr est de détruire physiquement le disque (pilonnage). :eusa-whistle:

#17

Et quand entre Gros_fichier ( :005 ) et le reste de la partition, il ne reste rien d’autre qu’un espace de survie pour le système de fichier en question ( quel qu’il soit) à votre avis il reste encore quelque chose des fichiers supprimés ?

Bon, si vous dites oui, je sens que je vais me faire moine ! et les moines hein ! :005 y zont la belle vie :smiley:

#18

Ben relis ce que j’ai marqué dans mon message précédent, et tu verras que ça peut arriver même sur les disques à plateau (les SSD j’en parle même pas). :wink:

#19

Non. La notion d’espace réservé ne définit pas un emplacement physique réservé, mais simplement une logique de fonctionnement.
Quand un utilisateur veut ajouter des données dans un fichier, nécessitant d’allouer des blocs :

  • tant qu’il reste plus d’espace libre que le pourcentage réservé, alors il peut écrire ;
  • s’il reste moins d’espace libre que le pourcentage réservé et si c’est root, il peut écrire ;
  • s’il reste moins d’espace libre que le pourcentage réservé et si ce n’est pas root, il ne peut pas écrire.

La conséquence est qu’un utilisateur non root ne pourra pas écraser toutes les données des fichiers supprimés en créant un gros fichier remplissant tout le disque, parce qu’il ne peut pas créer un fichier remplissant tout le disque. Et dans l’espace où il ne pourra pas écrire, il peut très bien rester des données des fichiers supprimés.

MEB ? Mec en bleu ?

#20

Ok, ça peut arriver que des données se retrouvent dans le “formol” de block défectueux, mais franchement la probabilité pour qu’un fichier entier s’y retrouve n’est pas nulle mais presque, et même dans ce cas ça reviendrait à ne chercher des fichiers effacé que dans ces blocks en questions, ce qui simplifierai la tâche quelque part, en tout c’est bien intéressant ce que vous dites ! :open_mouth: :smiley: :laughing: