3

Мне нужно использовать GPG для папки с большим количеством файлов и подпапок. Для этого я могу использовать "find" + "gpg" и шифровать все файлы, но моя проблема в том, что GPG не удаляет исходный файл после успешного шифрования.

Каков наилучший и наиболее безопасный способ удаления исходного файла (ов) после того, как GPG выполняет шифрование должным образом? Я не хочу преждевременно удалять свои файлы и не хочу неправильно удалять незашифрованные файлы (из-за ошибок, разрешений и т.д. При работе GPG).

Спасибо

1 ответ1

3

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

И если вы используете терминал, некоторые сценарии bash/sh могут быть полезны. Если вы хотите использовать проверку ошибок одной строкой? Вот так, чтобы переместить файл, если он правильно зашифрован, и напечатать сообщение, если это не так?

gpg --encrypt <options> "$file" && mv "$file" todel-folder || echo "Error, $file did not encrypt"

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

gpg --encrypt <options> "$file" && {
  echo "gpg on $file successful" >> logfile
  mv "$file" todel-folder
  } || {
  echo "Error, $file did not encrypt" >> logfile
}

А потом после этого , вы можете безопасно удалить / протирать / shred файлы в todel-folder или просто измельчать их сразу вместо того , чтобы использовать mv

gpg --encrypt <options> "$file" && {
    echo "gpg on $file successful" >> logfile
    shred "$file" && { 
        echo "shred on $file successful" >> logfile
        } ||  {
        echo "shred on $file successful" >> logfile
        }
    } || {
    echo "Error, $file did not encrypt" >> logfile
}

Смотрите man shred для некоторых вариантов и предупреждений:

shred - overwrite a file to hide its contents, and optionally delete it

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

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

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

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

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

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

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .