Як я рекурсивно подрібнюю все дерево каталогів?


47

У мене є дерево каталогів, яке я хотів би подрібнити за допомогою утиліти "клаптик" Linux. На жаль, клаптик не має -Rможливості для рекурсивного подрібнення.

Як я можу подрібнювати ціле дерево каталогів рекурсивно?

Відповіді:


45

Використовуйте findкоманду для shredрекурсивного виконання :

find <dir> -type f -exec shred {} \;

Чи працює без опції -depth? Чи працює це в сучасних файлових системах журналу?
користувач невідомий

@userunknown Ні, shred не працює в сучасних файлових системах журналу. Більш точну інформацію див man shred.
FanaticD

Також зауважте, що цей метод навіть не намагатиметься стерти імена файлів , тому будь-які збережені дані, безумовно, залишаться позаду ( srmвід відповіді Cookie @ принаймні буде спроба усунути цю проблему).
ntninja

Використовуйте, -exec shred {} +щоб зробити це швидше, оскільки shred приймає кілька аргументів.
Суміт

28

Остерігайся клаптиків!

З клаптикової сторінки:

ОБЕРЕЖНО: Зауважте, що shred спирається на дуже важливе припущення: що файлова система перезаписує дані на місці. Це традиційний спосіб робити речі, але багато сучасних дизайнів файлової системи не задовольняють це припущення. Нижче наведено приклади файлових систем, на яких клаптик не є ефективним або не гарантовано є ефективним у всіх режимах файлової системи:

  • Файлові системи, структуровані журналом, або такі, що застосовуються з журналом, такі як постачаються разом з AIX та Solaris (і JFS, ReiserFS, XFS, Ext3 тощо)

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

  • файлові системи, які роблять знімки, такі як NFS-сервер Network Appliance

  • файлові системи, які кешують у тимчасових місцях, таких як клієнти NFS версії 3

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

Що стосується файлових систем ext3, вищезазначена відмова від відповідальності застосовується (і, таким чином, клаптики мають обмежену ефективність) лише в режимі data = journal, в якому журнали зберігають дані на додаток до лише метаданих. І в режимах даних = упорядкований (за замовчуванням), і в даних = списання, клаптик працює як завжди. Режими журналу Ext3 можна змінити, додавши параметри data = щось у параметри кріплення для певної файлової системи у файлі / etc / fstab, як це зафіксовано на сторінці man monter (man mount).

Крім того, резервні копії файлової системи та віддалені дзеркала можуть містити копії файлу, які неможливо видалити, і це дозволить пізніше відновити подрібнений файл.

Рішення: Використовуйте зашифровану файлову систему та просто видаліть свої файли.


+1 для вказівника на клаптик, у мене був подібний випадок і раніше. Він не працював на NFS NetApp. NetApp використовує WAFL, і він використовує функцію копіювання при записі, включаючи метажурналізацію, тому її право. Також з останнім ZFS Solaris - ще один випадок, коли кладуть провали.
Nikhil Mulley

6
Це погане рішення. Зашифрована файлова система безпечна лише доти, до якої вона заблокована (і так відключена). Як тільки ваша ОС працює і працює, дані збираються.
олекс

3
@oleks: І використання, shredі шифрування даних перешкоджають зчитці даних із автономного пристрою зберігання даних (думайте, крадіжка або поліція) із шифруванням даних, що має додаткову перевагу захисту всіх файлів, а не лише тих, що видаляються (належним чином). Після того, як файлова система змонтована, ми повертаємося до хороших дозволів ol 'unix в будь-якому випадку, і захист даних знову стає завданням безпеки ОС та правильним адмініструванням системи. Попереднє шифрування файлової системи, безумовно, не гірше для захисту даних у спокої, ніж стратегічне використання shred!
ntninja

12

Замість цього використовуйте захищене видалення.

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

Зроблено. Безпечне видалення набагато більше параної, ніж шматок, використовуючи 38 проходів замість 3. Для швидкого однократного пропуску скористайтеся

srm -rfll pathname

Fll отримує менш генератор випадкових даних і лише один прохід.


Чи вирішує це питання, згадане в unix.stackexchange.com/a/27075/18886 ?
Іван Данн

Як це могло? Ні
Cookie

Зауважте, що цей метод має додаткову перевагу порівняно із запропонованими findметодами на основі запропонованих методів, які намагатимуться також стерти збережені назви файлів шляхом перейменування файлів перед обрізанням та від’єднанням їх.
ntninja

Методи на основі пошуку @ntninja використовують shred і shred перейменують файли, перш ніж закінчити, щоб видалити їх. Так же переваги правда?
tuxayo

11

Поєднуючи цю відповідь з найвідомішими варіантами для подрібнення за допомогою цього посилання для переповнення стека " Видалення файлів постійно та безпечно на 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

на кожен файл.


Прочитавши і вивчивши багато відповідей, я знайшов (імхо) цю відповідь найбільш ретельною. Я лише до цього додам, що оскільки shred не видаляє каталоги, я додав rm -rvf $1до скрипту оболонки (де $ 1 - / шлях / до / ваш / файл, переданий після {}розширення в find... -exec)
JoelAZ

4
shred вже робить fsync (2) після кожного проходу. Саме тому, що вам потрібно змусити зміни файлу дійти до диска до наступного проходу.
Анхель

Що depthтут роблять? Також невпевнений у
відхиленні від

5
find /your/directory -exec shred {} \;

Оголошено, але Джеймс побив вас одну хвилину, щоб прийняти.
Стів В.

Чи працює без опції -depth? Чи працює це в сучасних файлових системах журналу?
користувач невідомий

3
find [dirname] -depth -type f -exec shred -n1 {} \;

Це виконує пошук глибини спочатку для файлів у каталозі [dirname], після чого виконує shred -n1команду на кожному файлі. Видаляючи файли та / або каталоги, додавання -depthяк за замовчуванням є доброю звичкою, навіть якщо це строго не потрібно для цього випадку. При запуску цього виду команди з, rm -rfзамість shred, -depthнеобхідно забезпечити, щоб каталоги не видалялися до того, як вміст каталогів буде намагатися видалити (тим самим спричиняючи помилки).


3
Ви повинні використовувати shred -N 1, тому що за замовчуванням, подрібнюючи 3 рази, є зміїна олія. Або одного часу достатньо, або 30 разів не вийде.
користувач невідомий

Надання простої команди як відповіді - це не найкращий спосіб відповісти на запитання. Я рекомендую додати невелике пояснення щодо того, що робить лінія та можливі обмеження, пов'язані з її використанням.
n0pe

0

Найбільш ретельний shredметод, який я знайшов, і який включає видалення каталогів, - це findвикликати сценарій виклику shred:

  • перезаписати файл
  • синхронізація
  • потім видаліть
  • і нарешті зателефонуйте rm, щоб видалити імена каталогів.

Цей метод також належним чином обробляє імена файлів з пробілами в них.

По-перше - shredскрипт (я назвав mine 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файл виконуваним файлом ( chmod +x) і, звичайно, оновіть шлях до того режиму, який ви хочете подрібнити, і dirShredder.shякщо ви зберігаєте його деінде.

NOTA BENE - shredмає проблеми в файлових системах Copy-On-Write (ZFS, BTRFS тощо) та навіть у файлових системах Journaling. Немає реального прийнятого "найкращого" способу вирішити це, що я знайшов, крім "зашифрованих файлових систем", але я не впевнений, наскільки це ефективно після факту.
Найближче, що, здається, ви можете отримати, це перезаписати весь порожній простір на накопичувачі випадковими даними після вашої операції подрібнення (не нулі, здається, це не завжди надійно). Також, на SSD-дисках можуть бути і інші міркування (наприклад, TRIM.)

Я не збираюся входити до цих сюди, є інші відповіді на стек (наприклад, відповідь невідомого користувача в цьому запитанні) та безліч дискусій у мережі, що висвітлюють ці теми, тому шукайте їх, якщо вам потрібен такий рівень безпеки.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.