Ответы:
Используйте findкоманду для выполнения shredрекурсивно:
find <dir> -type f -exec shred {} \;
man shred.
srmиз ответа @ Cookie по крайней мере попытается решить эту проблему).
-exec shred {} +чтобы сделать это быстрее, так как shred принимает несколько аргументов.
Остерегайтесь клочья!
Из страницы клочка:
ВНИМАНИЕ: обратите внимание, что уничтожение основано на очень важном допущении: файловая система перезаписывает данные на месте. Это традиционный способ сделать что-то, но многие современные конструкции файловых систем не удовлетворяют этому предположению. Ниже приведены примеры файловых систем, в которых уничтожение неэффективно или не гарантируется, что оно будет эффективно во всех режимах файловой системы:
файловые системы со структурой журналов или журналами, например, поставляемые с AIX и Solaris (и JFS, ReiserFS, XFS, Ext3 и т. д.)
файловые системы, которые записывают избыточные данные и продолжают работу даже в случае сбоя при записи, например, файловые системы на основе RAID
файловые системы, которые делают снимки, такие как NFS-сервер сетевого устройства
файловые системы, которые кэшируются во временных расположениях, таких как клиенты NFS версии 3
сжатые файловые системы
В случае файловых систем ext3 вышеупомянутый отказ от ответственности применяется (и поэтому уничтожение имеет ограниченную эффективность) только в режиме data = journal, который регистрирует данные файла в дополнение только к метаданным. В режимах data = упорядоченный (по умолчанию) и data = writeback уничтожение работает как обычно. Режимы журналирования Ext3 можно изменить, добавив параметр data = кое-что к параметрам монтирования для конкретной файловой системы в файле / etc / fstab, как описано в справочной странице монтирования (man mount).
Кроме того, резервные копии файловой системы и удаленные зеркала могут содержать копии файла, которые нельзя удалить, и это позволит восстановить уничтоженный файл позже.
Решение: используйте зашифрованную файловую систему и просто удалите свои файлы.
shredи шифрование данных предотвращают считывание данных с автономного устройства хранения данных (например, кража или полиция) с помощью шифрования данных, что обеспечивает дополнительную защиту всех файлов, а не только удаленных (должным образом). Как только файловая система смонтирована, мы возвращаемся к хорошим старым разрешениям unix в любом случае, и защита данных снова становится задачей безопасности ОС и надлежащего администрирования системы. Предохранительное шифрование файловой системы определенно не хуже для защиты данных в состоянии покоя, чем стратегическое использование shred!
Вместо этого используйте безопасное удаление.
sudo apt-get install secure-delete
srm -r pathname
Готово. Безопасное удаление намного более параноидально, чем уничтожение, используя 38 проходов вместо 3. Для быстрого одиночного прохода используйте
srm -rfll pathname
fll дает вам менее случайный генератор данных и только один проход.
findметодами на основе, которые также будут пытаться стереть сохраненные имена файлов путем переименования файлов перед их усечением и отсоединением.
Сочетание этого ответа с наиболее известными вариантами уничтожения с помощью этой ссылки переполнения стека « Удаление файлов навсегда и безопасно в CentOS »:
find <directory> -depth -type f -exec shred -v -n 1 -z -u {} \;
Редактировать: Помните, что лучший ответ для уничтожения одного файла вызывает синхронизацию, которая записывает изменения на носитель перед удалением файла, потому что некоторые или все журнализированные файловые системы имеют буфер.
Если возможно, команда find должна вызвать скрипт оболочки для файла, который выполняется:
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
на каждом файле.
rm -rvf $1к сценарию оболочки (где $ 1 - файл / path / to / your /, переданный из {}расширения в find... -exec)
depthздесь делать? Также не уверен насчет обратной косой черты
find /your/directory -exec shred {} \;
find [dirname] -depth -type f -exec shred -n1 {} \;
При этом выполняется поиск в глубину файлов в каталоге [dirname], затем выполняется shred -n1команда для каждого файла. При удалении файлов и / или каталогов добавление -depthпо умолчанию является хорошей привычкой, хотя в этом случае это не является строго обязательным. При выполнении такого рода команды с rm -rfвместо shred, -depthнеобходимо обеспечить, чтобы каталоги не удалялись до того, как будет пытаться удалить содержимое каталогов (что приведет к ошибкам).
shred -N 1, потому что по умолчанию, измельчая 3 раза, змеиное масло. Либо одного раза достаточно, либо 30 раз не получится.
Самый тщательный shredметод, который я нашел, включая удаление каталогов, - это findвызвать скрипт для shred:
Этот метод также правильно обрабатывает имена файлов с пробелами в них.
Первый - shredскрипт (я назвал мой dirShredder.shи сохранил его в /rootкаталоге:
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
Затем вызовите скрипт следующим образом:
find /volume1/pathToShred/ -mindepth 1 -depth -exec /root/dirShredder.sh "{}" \;
Обязательно пометьте killit.shфайл executetable ( chmod +x) и, конечно, обновите путь к каталогу, который вы хотите уничтожить, и, dirShredder.shесли вы храните его где-то еще.
NOTA BENE - shredимеет проблемы с файловыми системами копирования при записи (ZFS, BTRFS и др.) И даже с файловыми системами журналирования. Не существует общепринятого «лучшего» способа справиться с этим, который я нашел, кроме «зашифрованных файловых систем», но я не уверен, насколько он эффективен по факту.
Самое близкое, что вы можете получить, - это перезаписать все пустое место на диске случайными данными после операций удаления (не нулями, кажется, это не всегда надежно.) Кроме того, у SSD могут быть и другие соображения (например, TRIM).
Я не буду вдаваться в подробности, есть и другие ответы в стеке (например, ответ @user unknown в этом вопросе) и множество обсуждений в сети, которые охватывают эти темы, поэтому ищите их, если вам нужен такой уровень безопасности.