Шред: Не работает на Journaled FS?

Question

В документации по уничтожению сказано, что уничтожение не обязательно будет эффективным (см. Внизу). Так что, если я уничтожу документ в моей файловой системе Ext3 или в Raid, что произойдет? Я уничтожаю часть файла? Иногда это уничтожает, а иногда нет? Это может уничтожить другие вещи? Разрывает только заголовок файла?

ВНИМАНИЕ: обратите внимание, что клочок опирается на очень важное предположение: что файловая система перезаписывает данные на месте. Это традиционный способ сделать что-то, но многие современные конструкции файловой системы не удовлетворить это предположение. Ниже приведены примеры файлов системы, в которых измельчение неэффективно или не гарантируется действует во всех режимах файловой системы:

• файловые системы с журнальной структурой или журналами, например, поставляемые с AIX и Solaris (и JFS, ReiserFS, XFS, Ext3 и т. Д.)

• файловые системы, которые записывают избыточные данные и продолжают работу даже в случае сбоя при записи, например, файловые системы на основе RAID

• файловые системы, создающие моментальные снимки, такие как NFS-сервер сетевого устройства

• файловые системы, которые кэшируют во временных расположениях, таких как клиенты NFS версии 3

• сжатые файловые системы

В случае файловых систем ext3 применяется приведенный выше отказ от ответственности. (и клочок, таким образом, имеет ограниченную эффективность) только в данных = журнал режим, который регистрирует данные файла в дополнение к метаданным. В оба типа data = упорядоченный (по умолчанию) и data = writeback, shred работает как обычно. Режимы журналирования Ext3 можно изменить, добавив параметр data = что-то для параметров монтирования определенная файловая система в файле / etc / fstab, как описано в man man page (man mount).

Answer 1

Все, что нужно, - это перезаписать, очистить, проверить успешность и повторить. Он абсолютно ничего не выясняет, приводит ли перезапись файла к блокам, содержащим исходные данные, которые будут перезаписаны. Это потому, что, не зная нестандартных вещей о базовой файловой системе, она не может.

Таким образом, журналируемые файловые системы не будут перезаписывать исходные блоки на месте, потому что это помешает их правильному восстановлению после ошибок, когда изменение наполовину записано. Если данные заносятся в журнал, то каждый проход уничтожения может быть записан в новое место на диске, и в этом случае ничего не уничтожается.

Файловые системы RAID (в зависимости от режима RAID) могут не перезаписывать все копии оригинальных блоков. Если есть избыточность, вы можете уничтожить один диск, но не другой (или другие), или вы можете обнаружить, что разные проходы влияли на разные диски, так что каждый диск был частично уничтожен.

В любой файловой системе аппаратное обеспечение диска может просто обнаружить ошибку (или, в случае флэш-памяти, применить выравнивание износа даже без ошибки) и переназначить логический блок на другой физический блок, так что оригинал помечен как неисправный (или неиспользованный), но никогда не перезаписывается.

Сжатые файловые системы могут не перезаписывать исходные блоки, потому что данные, которые перезаписывают уничтоженные фрагменты, являются либо случайными, либо чрезвычайно сжимаемыми на каждом проходе, и любая из них может привести к радикальному изменению размера сжатого файла и, следовательно, его перемещению. NTFS хранит небольшие файлы в MFT, и когда крошка округляет размер файла до кратного одного блока, его первое «перезапись» обычно приводит к перемещению файла в новое место, которое затем бессмысленно уничтожается, оставляя небольшое количество файлов. Слот MFT нетронут.

Шред не может обнаружить ни одно из этих условий (если у вас нет специальной реализации, которая напрямую обращается к вашему fs и блочному драйверу - я не знаю, существуют ли такие вещи на самом деле). Вот почему он более надежен при использовании на целом диске, чем в файловой системе.

Шред никогда не уничтожает "другие вещи" в смысле других файлов. В некоторых случаях выше он уничтожает ранее нераспределенные блоки вместо блоков, которые содержат ваши данные. Он также не уничтожает метаданные в файловой системе (что, я думаю, вы подразумеваете под «заголовком файла»). Опция -u пытается перезаписать имя файла, переименовывая в новое имя такой же длины, а затем сокращая этот символ за раз до 1 символа, перед удалением файла. Вы можете увидеть это в действии, если вы укажете и -v.

Answer 2

Другие ответы уже хорошо объяснили, почему Шред не может выполнять свою работу должным образом.

Это можно суммировать как:

shred работает только с разделами, а не с отдельными файлами

Как объясняется в других ответах, если вы уничтожите один файл:

• нет никакой гарантии, что реальные данные действительно будут перезаписаны, потому что файловая система может отправлять записи в один и тот же файл в разные места на диске
• нет никаких гарантий, что ФС не создавал копии данных в других местах
• ФС может даже решить «оптимизировать» ваши записи, потому что вы пишете один и тот же файл несколько раз (синхронизация должна предотвратить это, но опять-таки: без гарантии)

Но даже если вы знаете, что ваша файловая система не делает ничего из вышеперечисленного, вы также должны учитывать, что многие приложения будут автоматически создавать копии файловых данных:

• файлы восстановления после сбоя, которые текстовые процессоры, редакторы (например, vim) и т. Д. Будут периодически записывать
• миниатюры / файлы предварительного просмотра в файловых менеджерах (иногда даже не для файлов изображений)
• временные файлы, которые используют многие приложения

Итак, если не проверять каждый двоичный файл, который вы используете для работы с вашими данными, он мог быть скопирован вправо, влево и по центру без вашего ведома. Единственный реалистичный способ - всегда уничтожать полные разделы (или диски).

Answer 3

Проблема заключается в том, что данные могут существовать в нескольких местах на диске. Когда данные существуют только в одном месте, уничтожение может детерминистически «стереть» эту информацию. Однако файловые системы, которые ведут журнал, или другие расширенные файловые системы могут временно записывать данные вашего файла на диск в нескольких местах. По факту, Шред не может знать об этом и не может знать, где данные могли быть временно записаны на диск. Таким образом, он не может стереть или перезаписать эти сектора диска.

Представьте себе следующее: вы записываете файл на диск в журнализированной файловой системе, в которой записываются не только метаданные, но и данные файла. Данные файла временно записываются в журнал, а затем записываются в его окончательное местоположение. Теперь вы используете крошку на файл. Конечное место, где были записаны данные, может быть безопасно перезаписано в клочья. Однако у shred должен быть какой-то способ гарантировать, что сектора в журнале, которые временно содержали содержимое вашего файла, также будут перезаписаны, чтобы можно было пообещать, что ваш файл действительно не подлежит восстановлению. Представьте себе файловую систему, в которой журнал даже не находится в фиксированном месте или не имеет фиксированной длины.

Если вы используете шред, то вы пытаетесь убедиться, что ваши данные не могут быть восстановлены. Авторы shred честно говорят, что есть некоторые условия вне их контроля, когда они не могут дать эту гарантию.