“Легкий” способ надежно удалить файлы на поле Unix?
Инструменты командной строки, как "клочок", идут со многими правовыми оговорками о ситуациях, где они не могут надежно удалить файлы. У меня была идея для cheap'n'easy способа сделать это и требуемый совет.
Как насчет того, чтобы выполнить "dd" от/dev/zero и пытаться создать файл, больше, чем остающееся пространство на разделе. Конечно, это заполнит базовые блоки всеми нулями и, после того как это умирает за исчерпывание дискового пространства, Вы просто удалили бы этот файл.
Таким образом, я думаю, любая утилита восстановления, которая пытается исследовать базовый диск, только видела бы нули, неважно, где это смотрит...
Да, это было бы неэффективно на большом разделе, но что в стороне - насколько нормальный это?....
4 ответа
Если у Вас была система без других процессов, работающих, который, возможно, должен был бы получить доступ (или доступ причины) к диску, то да, который мог бы работать, но это чрезвычайно неэффективно. Идеально Вы определили бы используемые дисковые блоки, удостоверились бы, что ни один из блоков не был повторно отображен контроллером диска и переписывает блок данных с большим разнообразием значений, многократно чтобы гарантировать, что никакой остаточный отпечаток не остается.
Не будет работать.
То, что делают программы как "клочок", записать случайный мусор на всем протяжении диска, используемого файлом - несколько раз.
Просто запись нулей все еще оставит "отпечаток" исходных данных. Даже если Вы несколько раз делаете это.
Это также неэффективно. У Вас могут быть области HUGE диска, которые никогда не писались в это, Вы проводите часы, пишущий нули в ни по какой причине. Намного более эффективно просто перезаписать области, на самом деле используемые данным файлом.
Проблема отпечатков, если это существует, может быть решена путем определения источника от/dev/urandom вместо/dev/zero. Или даже, так как производительность, кажется, не имеет важности вообще в предпосылке, не получает ее от/dev/random.
У Вас все еще была бы проблема с повторно отображенными дисковыми блоками, особенно в ssds. Если один из блоков, в которые Вы записали свои уязвимые данные, будет считать дефектным встроенное микропрограммное обеспечение, то это будет заменено резервным блоком и ликвидировано, содержание, скопированное в заменяющий блок. Файловая система ничего не видит от этого, Ваши уязвимые данные недоступны из Вашего программного обеспечения, но все еще доступны судебными методами. Вы не сможете достигнуть и перезаписать этот блок на пенсии с Вашими уязвимыми данными на нем любым основанным на программном обеспечении подходом.
DD был бы очень плохим выбором. Это - находящийся на секторе инструмент копии. Это не заботится о том, какие данные находятся в тех секторах. Насколько я знаю, DD не имеет никакого понятия свободного пространства или файлов. Я обновил от 120 ГБ до HD на 320 ГБ в моем ноутбуке, и DD скопировал 120 ГБ данных, даже при том, что у меня действительно было свободных 30 ГБ. (это было действительно довольно прохладно, не должен был даже делить его, это просто скопировало все разделы, удаленные файлы, подкачку, и т.д.),
Не говоря уже о, свободное пространство не непрерывно, его часто рассеянный на всем протяжении диска. Таким образом, Вы не можете только сказать, "перезаписывают вторую половину диска", потому что его единственное, наполовину полное, потому что данные будут на всем протяжении диска.