Journal Suppression d'un fichier, suppression des données du fichier

Posté par srb (site web personnel) le 03 décembre 2009 à 01:02.

Étiquettes : aucune

-3

déc.

2009

Lorsqu'on supprime des fichiers (en utilisant la commande rm ou une interface graphique), le système de fichier ne supprime pas réellement les données mais juste le pointeur qui permet d'y accéder, appelé un inode. Ce comportement permet d'augmenter largement les performances du système de fichier. En effet dans le cas contraire, il faudrait autant de temps pour écrire ou pour supprimer un fichier. En ne supprimant que l'inode, la suppression est instantanée.

Cependant, il existe des cas où l'on souhaite réellement que les données soient supprimées (pour être sûr que les données ne soient pas récupérables). Dans ce cas, certains systèmes de fichiers permettent de modifier leur comportement pour qu'ils détruisent réellement les données, au prix d'une baisse de performance. Libre à chacun d'évaluer sa priorité entre la performance et la confidentialité.

Pourquoi ne pas juste avoir un outil pour effacer les données de fichiers uniquement lorsqu'on le souhaite? C'est ce que je me suis demandé hier soir et je vous livre mes quelques réflexions. Un prototype en shell me semble assez trivial à écrire:

TAILLE=`du -b ${1}|cut -f1` #nombre d'octets du fichier
dd bs=1 count=$TAILLE if=/dev/zero of=fichier_a_supprimer
rm fichier_a_supprimer

Cependant, le système d'exploitation doit pouvoir mettre les données en cache et donc ne pas les écrire car la suppression arrivera probablement avant le vidage du cache. Un simple "sync" entre la commande "dd" et "rm" devrait contourner ce problème.

D'un autre côté, pourquoi créerr une nouvelle commande alors que ça pourrait être intégré à "rm" via une nouvelle option?

Voilà ce à quoi un script shell pourrait ressembler (appelons-le "rwrm" pour ReWrite and ReMove ou "destroy", parce que ça fait impressionnant) :

#! /bin/sh
# détruit les données du fichier passé en paramètre puis l'efface
# j'espère qu'il n'y a pas de spécificités bash...

SCRIPTNAME="rwrm"
ARGS=1

f_usage() {
echo "Syntaxe: ${SCRIPTNAME} fichier_a_supprimer"
}

# Vérifie si le script est correctement appelé.
if [ $# -ne ${ARGS} ]
then
f_usage
exit 1
fi

if [ ! -f ${1} ]
then
echo "${1} introuvable (ou n'est pas un fichier)."
exit 2
fi

TAILLE=`du -b ${1}|cut -f1` # nombre d'octets du fichier
#sync # utile?
dd bs=1 count=$TAILLE if=/dev/zero of=${1}
rm ${1}

# fin du script

Note pour le jour où j'aurais du temps à perdre: l'implémentation en C me semble facile à réaliser.

# SHRED(1)

Posté par stricaud le 03 décembre 2009 à 01:08. Évalué à 10.

shred -u file
# Et aussi

Posté par Nicolas Noirbent le 03 décembre 2009 à 01:52. Évalué à 2.

En sus du commentaire ci-dessus, je me permettrais de faire remarquer qu'un certain nombre de systèmes de fichiers modernes (dont ext3, XFS…) n'écrasent pas les données en place.

Ce qui signifie que « bêtement » réécrire des 0 par dessus le fichier cible ne détruira en aucun cas les données initiales sur la partition du disque dur sous-jacent; je n'évoque même pas les cas ou ladite partition est en réalité un volume LVM / une partition RAID.
- [^] # Re: Et aussi
  
  Posté par Octabrain le 03 décembre 2009 à 02:02. Évalué à 3.
  
  "En sus du commentaire ci-dessus, je me permettrais de faire remarquer qu'un certain nombre de systèmes de fichiers modernes (dont ext3, XFS…) n'écrasent pas les données en place."
  (Sans prendre en compte la journalisation) Ah bon, et ils font quoi alors ? (je te prie de donner au moins un lien pour prouver ce que tu vas dire)
  - [^] # Re: Et aussi
    
    Posté par fleny68 le 03 décembre 2009 à 02:10. Évalué à 8.
    
    De mémoire, les FS change les fichiers de place s'ils changent de taille.
    
    Ce qui fait qu'effacer physiquement le fichier avec shred ne garantit pas que les données ne se retrouvent pas ailleurs sur le disque.
    - [^] # Re: Et aussi
      
      Posté par Octabrain le 03 décembre 2009 à 11:59. Évalué à 2.
      
      "De mémoire, les FS change les fichiers de place s'ils changent de taille."
      Tout le problème de son raisonnement est là, shred ne fait pas changer de taille les fichiers (à part qu'il doit arrondir aux blocs de 512 octets, mais le fs ne devrait pas changer de place le fichier dans les limites d'un bloc)
    - [^] # Re: Et aussi
      
      Posté par Octabrain le 03 décembre 2009 à 12:19. Évalué à 4.
      
      Ou alors voulais-tu dire que le fichier avait changé de place plusieurs fois dans son existence, bien avant le shred, et des versions précédentes du fichiers vont se trouver éparpillées sur le disque ? Oui, ça peut être valable.
      - [^] # Re: Et aussi
        
        Posté par Octabrain le 03 décembre 2009 à 12:29. Évalué à 4.
        
        Je me demande ce que vaut ce genre d'outils : http://packages.debian.org/sid/zerofree
        
        [^] # Re: Et aussi
        
        Posté par Boa Treize (site web personnel) le 04 décembre 2009 à 18:04. Évalué à 3.
        
        Devrait être bien efficace en théorie, bien plus que le classique remplissage du disque par des zéros. Remarque qu'il ne fonctionne que sur un système de fichiers monté en lecture seule.
  - [^] # Re: Et aussi
    
    Posté par fleny68 le 03 décembre 2009 à 02:18. Évalué à 2.
    
    http://linuxfr.org/forums/10/23995.html
    - [^] # Re: Et aussi
      
      Posté par Octabrain le 03 décembre 2009 à 12:05. Évalué à 2.
      
      J'avais fait exprès d'écrire "Sans prendre en compte la journalisation" en premier dans mon message, mais erreur fatale, je l'ai mis entre parenthèses, alors ton cerveau a oublié de le lire...
  - [^] # Re: Et aussi
    
    Posté par wismerhill le 03 décembre 2009 à 08:49. Évalué à 2.
    
    Ils font du
    http://en.wikipedia.org/wiki/Copy-on-write
    - [^] # Re: Et aussi
      
      Posté par pix (site web personnel) le 03 décembre 2009 à 09:46. Évalué à 1.
      
      Et sur des système de fichier du style de LogFS, c'est encore moins efficace ;)
      
      LFS: A Log Structured File System for Linux that Supports Snapshots
      
      - http://lwn.net/Articles/234441/
      - http://logfs.org/logfs/
    - [^] # Re: Et aussi
      
      Posté par Octabrain le 03 décembre 2009 à 12:12. Évalué à 1.
      
      Ton lien ne prouve rien, COW est un principe général qui est utilisé pour économiser de la place en partageant des données entre 2 entités qui pourront cependant évoluer séparément, comme par exemple la mémoire de 2 processus juste après un fork().
      Dans le cas général, je ne vois pas pourquoi un FS utiliserait ça, et c'est pas ton lien qui le montre. Dans les cas particuliers, ça peut être utilisé pour faire des backups par exemple, comme avec ext3cow [http://www.ext3cow.com/] (mais ce n'est pas le ext3 qu'on trouve dans linux, attention).
      - [^] # Re: Et aussi
        
        Posté par wismerhill le 04 décembre 2009 à 19:17. Évalué à 1.
        
        http://en.wikipedia.org/wiki/Zfs#Copy-on-write_transactional(...)
        
        http://en.wikipedia.org/wiki/Btrfs
        
        [^] # Re: Et aussi
        
        Posté par Octabrain le 04 décembre 2009 à 19:45. Évalué à 1.
        
        Tu les lis tes liens avant de les balancer ?
        
        Selon la page btrfs, copy-on-write est utilisé pour les snapshots (rien à voir avec le sujet), et dans le cas de "clonage" de fichier, lors d'un "cp", donc avec 2 inodes différents, ce qui n'affecte en rien l'effet du shred. Ce lien ne sert donc à rien.
        
        La page zfs parle aussi de copy-on-write pour les snapshots (ce qui n'a toujours rien à voir), ainsi que pour avoir des "transactions" sur les fichiers, ce qui est en rapport avec le sujet, et effectivement c'est mauvais signe pour shred.
        
        Tu remarqueras que les exemples que tu donnes n'ont rien à voir avec ceux invoqués dans le post initial : ext3 et xfs.
        
        [^] # Re: Et aussi
        
        Posté par wismerhill le 05 décembre 2009 à 00:04. Évalué à 1.
        
        Le commentaire d'origine parlait de systèmes de fichiers modernes et citait ext3 et xfs en exemples avec points de suspension, donc si je suis dans le sujet avec btrfs et zfs.
        
        Le fait que le copy-on-write ne soit utilisé que dans certains cas particulier implique malgré tout que, sur ces systèmes de fichiers, on n'a pas de garantie que les données sensibles ne traînent pas ailleurs sur le disque dur, à moins de connaître parfaitement l'historique d'utilisation de son FS et d'être sur que l'on n'a pas utilisé les fonctionnalités en question.
        
        [^] # Re: Et aussi
        
        Posté par Psychofox (Mastodon) le 05 décembre 2009 à 11:08. Évalué à 2.
        
        Je crois mon pauvre amis que sais toi qui ne lis pas (ou plutôt dans ce cas la, qui ne sait pas lire)
        
        zfs fait toujours du copy-on-write. C'est aussi la raison pour laquelle il n'y a pas d'outil de fsck par exemple, car ça ne servirait à rien.
        
        La page wikipedia explique juste plus bas que l'usage du copy-on-write facilite la création de snapshots, ce qui est évident.
- [^] # Re: Et aussi
  
  Posté par KiKouN le 03 décembre 2009 à 11:09. Évalué à 2.
  
  il ne faut pas aussi oublier les SSD qui vont aller écrire dans un autre bloc pour préserver la durée de vie du SSD.
  - [^] # Re: Et aussi
    
    Posté par Octabrain le 03 décembre 2009 à 12:14. Évalué à 2.
    
    Ah, ça c'est effectivement bien plus valable comme argument, mais ce ne sont pas les "XFS, ext3", comme le dit le commentaire auquel tu réponds, qui s'en chargent.
# c'est la course

Posté par theblatte le 03 décembre 2009 à 02:24. Évalué à 4.

Il y a une race entre le moment où tu calcules la taille du fichier et le moment où tu écris dedans avec dd (le fichier peut très bien changer de taille entre-temps).

Sinon, pas mieux que les commentaires au-dessus...
# Tout est dans le commentaire.

Posté par Axioplase ıɥs∀ (site web personnel) le 03 décembre 2009 à 05:29. Évalué à 2.

http://linux.about.com/library/cmd/blcmdl1_shred.htm
# rm ne supprime pas toujours l'i-node

Posté par 🚲 Tanguy Ortolo (site web personnel) le 03 décembre 2009 à 09:28. Évalué à 10.

rm, ça supprime le lien vers un fichier. Si le compteur de liens du fichier tombe à zéro, ça supprime l'i-node, sinon ça le laisse !
# Raté

Posté par Thomas Petazzoni (site web personnel) le 03 décembre 2009 à 09:42. Évalué à 10.

juste le pointeur qui permet d'y accéder, appelé un inode.

Raté, l'inode c'est ce qui référence les données. Le pointeur, c'est une entrée de répertoire, ou dentry dans la terminologie du noyau.
# outils et outillage

Posté par bubar🦥 (Mastodon) le 03 décembre 2009 à 10:12. Évalué à 3.

Il existe déjà des outils pour faire cela, mais l'exercice est toujours fort sympathique.
Ce qui serait peut être intéressant, c'est de pouvoir proposer une "corbeille" dans laquelle l'utilisateur peut faire un "glisser déposer" des dits fichiers, et avoir toutes données et références écrasées. Dit comme cela, c'est facile, mais même en utilisant de zouettes outils tout prêt, l'exerice reste 'dur'.

Sinon sincèrement mon nanavis est que cela met en lumière une possibilité, et améliore la compréhension pour l'utilisateur de son système, et ça c'est bien :p Mais une fois un peu éclairé, il souhaitera peut être plutôt se préparer des espaces dédiés à la manipulation de données sensibles.
- [^] # Re: outils et outillage
  
  Posté par Olorim le 03 décembre 2009 à 11:19. Évalué à 2.
  
  Nan, pas une corbeille, un broyeur serai plus parlant comme image.
  
  Mais bon, avant de parler de graphique, il faudrait que le mécanisme soit fiable déjà : le meilleur moyen, c'est d'écrire un fichier au même endroit avec du contenu aléatoire de même taille que le précèdent et de de supprimer ce fichier ensuite. Ok, coté performance ça doit pas être le pied, mais je vois pas de meilleur moyen...
  - [^] # Re: outils et outillage
    
    Posté par Octabrain le 03 décembre 2009 à 12:16. Évalué à 4.
    
    Cette image de "broyeur" sur laquelle déposer des fichiers existait déjà dans kde3 au moins, c'était kgpg si je me souviens bien qui proposait d'ajouter une telle icone sur le bureau.
    - [^] # Re: outils et outillage
      
      Posté par Fabimaru (site web personnel) le 03 décembre 2009 à 16:46. Évalué à 1.
      
      Et dans OS/2 il me semble.
      - [^] # Re: outils et outillage
        
        Posté par Fabimaru (site web personnel) le 03 décembre 2009 à 16:48. Évalué à 2.
        
        Voila!
        
        http://toastytech.com/guis/os24_1stscreen.gif
  - [^] # Re: outils et outillage
    
    Posté par Kerro le 03 décembre 2009 à 12:57. Évalué à 4.
    
    M'est avis que le seul moyen fiable soit une API que chaque système de fichier puisse comprendre. C'est le cas pour ZFS, et probablement d'autres. Mais je ne crois pas que les outils standards s'en préoccupent.
# Les attributs des fichiers d'un système de fichiers Linux

Posté par Frédéric Massot (site web personnel) le 03 décembre 2009 à 11:20. Évalué à 7.

En lisant ce message, je me suis dis : "Mais il y a les attributs pour cela !!! man chattr"

Et bien non, si il y a bien un attribut pour la mise à zéro des blocs d'un fichier lors de sa suppression, il n'est pas respecté par les noyaux actuel. Extrait de la page du manuel de chattr :

Quand un fichier avec l'attribut « s » est supprimé, ses blocs sont mis à zéro et écrits sur le disque. Remarque : assurez-vous de lire la section sur les bogues et limitations à la fin de ce document.

Les attributs « c », « s » et « u » ne sont pas respectés par les systèmes de fichiers ext2 et ext3 tels qu'ils sont implémentés dans les noyaux Linux actuels. La gestion de ces attributs pourrait être implémentée dans des versions futures des systèmes de fichiers ext2 et ext3.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.