Безопасно ли изменять основные зашифрованные файлы для подключенного тома ecryptfs?

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

Предположим, я поместил базовые данные ecryptfs в:

/home/user/.Private

И я монтирую этот каталог по адресу:

/home/user/unlocked

Могу ли я обновить файлы в .Private (например, с помощью rsync) и ожидать unlocked отразить изменения? Или это просто испортит ситуацию? Есть ли лучшие альтернативы для прямой синхронизации зашифрованных данных?

ОБНОВЛЕНИЕ, чтобы уточнить:

Я хочу только когда-либо передавать зашифрованные данные на сервер - сервер не является доверенным. Итак, я хочу увидеть:

 client <-- encrypted data --> server

Может быть более одного клиента, обновляющего (расшифровывающего) файлы; отсюда и желание живой синхронизации:

 client1
        \
         \--- encrypted data --\
                                \
                                 server
                                /
         /--- encrypted data --/
        /
 client2

Таким образом, у клиента есть каталог, содержащий зашифрованные файлы - chunked так, как это делает ecryptfs:

/home/client1/.Private/
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Fabcde.../
                 |                                    |--- ECRYPTFS_FNEK_...
                 |
                 |--- ECRYPTFS_FNEK_ENCRYPTED.Flaksd.../
                                                      |--- ...

Это смонтировано с помощью ecryptfs:

/home/client1/unlocked/
                 |--- secret_file_1
                 |--- secret_file_2

Теперь client1 усердно вносит изменения в файлы в unlocked, Когда клиент вносит изменения, основные зашифрованные файлы в .Private изменить также. Таким образом, локальное inotify или некоторые такие уведомления об изменениях и rsyncs зашифрованных базовых файлов в .Private на сервер. Сервер, зная, что client2 также прослушивает, уведомляет client2, что он должен получить изменения.

Поэтому я обеспокоен тем, что: если client2 извлекает базовые фрагментированные файлы encryptfs в.Private, пока он монтируется в unlockedЯ подозреваю, что это вызовет проблемы, нет? Это потребует, чтобы client2 размонтировал unlocked до синхронизации, которая побеждает всю идею "живой синхронизации".

Если да, то каковы хорошие альтернативные методы для эффективной синхронизации различий зашифрованного дерева?

Источник

2 ответа

Решение

По словам Тайлера Хикса (одного из сопровождающих eCryptfs), в настоящее время небезопасно изменять базовую файловую систему (нижняя файловая система в терминологии eCryptfs):

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

Даже если бы мы могли их обнаружить, как бы мы связали их с грязными страницами eCryptfs? Как мы узнаем, какие самые свежие данные?

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

Источник: https://bugs.launchpad.net/bugs/689030

Источник

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

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

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

полезная информация здесь

Источник
Другие вопросы по тегам