Измельчить:Не работает с журналируемыми FS?

Question

В документации Shred говорится, что shred "не гарантированно эффективен" (см. Внизу).Итак, если я уничтожу документ в своей файловой системе Ext3 или в Raid, что произойдет?Удаляю ли я часть файла?Иногда это разрушает все целиком, а иногда нет?Может ли это измельчить другие вещи?Удаляет ли это только заголовок файла?

ОСТОРОЖНО:Обратите внимание, что shred опирается на очень важное предположение:что файловая система перезаписывает данные на месте.Это традиционный способ делать что-то, но многие современные конструкции файловых систем не удовлетворяют этому предположению.Ниже приведены примеры файловых систем, на которых shred неэффективен или не гарантированно будет эффективен эффективен во всех режимах файловой системы:

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Это можно резюмировать следующим образом:

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

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

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

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

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

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

Answer 3

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

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

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