¿Cómo destruyo recursivamente un árbol de directorios completo?

48

Tengo un árbol de directorios que me gustaría destruir con la utilidad 'triturar' de Linux. Desafortunadamente, la trituración no tiene -Ropción para la trituración recursiva.

¿Cómo puedo triturar un árbol de directorios completo de forma recursiva?

Steve V.
fuente

Respuestas:

46

Use el findcomando para ejecutar shredrecursivamente:

find <dir> -type f -exec shred {} \;
jamesallman
fuente
¿Funciona sin la opción de profundidad? ¿Funciona en sistemas modernos de archivos de diario?
usuario desconocido
@userunknown No, shred no funciona en los sistemas modernos de archivos de registro en diario. Para obtener información más precisa, consulte man shred.
FanaticD
También tenga en cuenta que este método ni siquiera intentará borrar los nombres de los archivos , por lo que cualquier información almacenada como esta definitivamente se quedará atrás ( srmde la respuesta de @ Cookie al menos intentará evitar este problema).
ntninja
Úselo -exec shred {} +para hacerlo más rápido ya que shred acepta múltiples argumentos.
Sumit
28

¡Cuidado con la trituración!

Desde la página de manual de trituración:

PRECAUCIÓN: Tenga en cuenta que triturar se basa en una suposición muy importante: que el sistema de archivos sobrescribe los datos en su lugar. Esta es la forma tradicional de hacer las cosas, pero muchos diseños modernos de sistemas de archivos no satisfacen esta suposición. Los siguientes son ejemplos de sistemas de archivos en los que la trituración no es efectiva o no se garantiza que sea efectiva en todos los modos del sistema de archivos:

  • sistemas de archivos con estructura de registro o diarios, como los suministrados con AIX y Solaris (y JFS, ReiserFS, XFS, Ext3, etc.)

  • sistemas de archivos que escriben datos redundantes y continúan incluso si algunas escrituras fallan, como los sistemas de archivos basados ​​en RAID

  • sistemas de archivos que hacen instantáneas, como el servidor NFS de Network Appliance

  • sistemas de archivos que se almacenan en caché en ubicaciones temporales, como clientes NFS versión 3

  • sistemas de archivos comprimidos

En el caso de los sistemas de archivos ext3, el descargo de responsabilidad anterior se aplica (y la destrucción es, por lo tanto, de efectividad limitada) solo en el modo datos = diario, que registra los datos de los archivos además de solo los metadatos. En los modos de datos = ordenados (predeterminado) y de datos = reescritura, la trituración funciona como de costumbre. Los modos de registro en diario Ext3 se pueden cambiar agregando la opción data = something a las opciones de montaje para un sistema de archivos en particular en el archivo / etc / fstab, como se documenta en la página de manual de montaje (montaje de hombre).

Además, las copias de seguridad del sistema de archivos y las réplicas remotas pueden contener copias del archivo que no se pueden eliminar y que permitirán recuperar un archivo triturado más adelante.

Solución: utilice un sistema de archivos cifrado y simplemente elimine sus archivos.

usuario desconocido
fuente
+1 para puntero en trituración, tuve un caso similar antes. No funcionó en NFS de NetApp. NetApp utiliza WAFL y que utiliza copia en escritura, incluyendo metajournalling, por lo que es correcto. También con el último ZFS de Solaris hay otro caso en el que se eliminan los restos.
Nikhil Mulley
66
Esta es una mala solución. Un sistema de archivos cifrados solo es seguro mientras esté bloqueado (y desmontado). Tan pronto como su sistema operativo esté en funcionamiento, los datos estarán disponibles.
oleks
3
@oleks: tanto el uso shredcomo el cifrado de datos impiden leer los datos de un dispositivo de almacenamiento fuera de línea (piense en el robo o la policía) con el cifrado de datos que tiene el beneficio adicional de proteger todos los archivos, no solo los que se eliminan (correctamente). Una vez que se monta el sistema de archivos, volvemos a tener buenos permisos de Unix en cualquier caso y la protección de datos se convierte en una tarea de seguridad del sistema operativo y la administración adecuada del sistema nuevamente. ¡El cifrado inicial del sistema de archivos definitivamente no es peor para proteger los datos en reposo que el uso estratégico de shred!
ntninja
12

Utilice la eliminación segura en su lugar.

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

Hecho. La eliminación segura es mucho más paranoica que la destrucción, utilizando 38 pases en lugar de 3. Para hacer un solo pase rápido, use

srm -rfll pathname

fll te da un generador de datos menos aleatorio, y solo una pasada.

Galleta
fuente
¿Resuelve el problema mencionado en unix.stackexchange.com/a/27075/18886 ?
Ian Dunn el
Como podria No
Cookie
Tenga en cuenta que este método tiene la ventaja adicional sobre los findmétodos basados ​​en propuestas que tratarán de borrar también los nombres de archivos almacenados cambiando el nombre de los archivos antes de truncarlos y desvincularlos.
ntninja
Los métodos basados ​​en la búsqueda de @ntninja usan shred y shred cambia el nombre de los archivos antes de terminar para eliminarlos. Entonces, ¿los mismos beneficios, verdad?
tuxayo
11

Combinando esta respuesta con las opciones más conocidas para triturar usando este enlace de desbordamiento de pila ' Eliminar archivos de forma permanente y segura en CentOS ':

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

Editar: Tenga en cuenta que la mejor respuesta para destruir un solo archivo fuerza una sincronización que escribe los cambios en los medios antes de eliminar el archivo porque algunos o todos los sistemas de archivos registrados tienen un búfer.

Si es posible, el comando find debería llamar a un script de shell en el archivo que se ejecuta:

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

en cada archivo

im3r3k
fuente
Después de leer e investigar muchas respuestas, encontré (en mi humilde opinión) esta respuesta como la más completa. Solo agregaría que, dado que shred no elimina los directorios que agregué rm -rvf $1al script de shell (donde $ 1 es el / path / to / your / file pasado de la {}expansión en el find... -exec)
JoelAZ
44
shred ya realiza fsync (2) después de cada pasada. Precisamente porque necesita forzar los cambios del archivo para que lleguen al disco antes del próximo paso.
Ángel
Que hace depthaqui Tampoco
estoy
5
find /your/directory -exec shred {} \;

fuente
Votó, pero James te ganó por un minuto para aceptar.
Steve V.
¿Funciona sin la opción de profundidad? ¿Funciona en sistemas modernos de archivos de diario?
usuario desconocido
3
find [dirname] -depth -type f -exec shred -n1 {} \;

Esto realiza una búsqueda profunda de los archivos en el directorio [dirname], luego ejecuta el shred -n1comando en cada archivo. Al eliminar archivos y / o directorios, agregar de -depthforma predeterminada es un buen hábito, aunque no es estrictamente necesario para este caso. Cuando se ejecuta este tipo de comando con en rm -rflugar de shred, -depthes necesario para garantizar que los directorios no se eliminen antes de que se intente eliminar el contenido de los directorios (lo que provoca errores).

Alejandro
fuente
3
Debe usar shred -N 1, porque el valor predeterminado, triturar 3 veces, es el aceite de serpiente. Una vez es suficiente o 30 veces no funcionará.
usuario desconocido
Proporcionar un comando simple como respuesta no es la mejor manera de responder una pregunta. Recomendaría agregar una pequeña explicación sobre lo que está haciendo la línea y las posibles limitaciones relacionadas con su uso.
n0pe
0

El shredmétodo más completo que he encontrado, que también incluye la eliminación de directorios, es findllamar a un script para que tenga shred:

  • sobrescribir el archivo
  • sincronizar
  • luego eliminar
  • y finalmente llame a rm para eliminar los nombres de directorio.

Este método también maneja correctamente los nombres de archivo con espacios en ellos.

Primero: el shredscript (he nombrado el mío dirShredder.shy lo he almacenado en el /rootdirectorio:

shred -v -n 1 "$1" #overwriting with random data
sync #forcing a sync of the buffers to the disk
shred -v -n 0 -z -u "$1" #overwriting with zeroes and remove the file
rm -rvf "$1" # call rm to remove the directories

Luego, llame al script de esta manera:

find /volume1/pathToShred/ -mindepth 1 -depth -exec /root/dirShredder.sh "{}" \;

Asegúrese de marcar el killit.sharchivo ejecutable ( chmod +x) y, por supuesto, actualice la ruta del directorio que desea destruir y dirShredder.shsi lo almacena en otro lugar.

NOTA BENE: shredtiene problemas en los sistemas de archivos de Copia en escritura (ZFS, BTRFS, et al) e incluso en los sistemas de archivos de Journaling. No hay una "mejor" forma aceptada real de lidiar con esto que he encontrado que no sean "sistemas de archivos cifrados", pero no estoy seguro de cuán efectivo es esto después del hecho.
Lo más cercano que parece que puede obtener es sobrescribir todo el espacio vacío en la unidad con datos aleatorios después de sus operaciones de trituración (no ceros, parece que esto no siempre es confiable). Además, los SSD también pueden tener otras consideraciones (como TRIM).

No voy a entrar en eso aquí, hay otras respuestas de Stack (la respuesta de @user unknown en esta pregunta, por ejemplo) y muchas discusiones en la red que cubren estos temas, así que búsquelas si necesita ese nivel de seguridad.

JoelAZ
fuente