Я хочу выполнить синхронизацию зашифрованного каталога с сервером в реальном времени, чтобы сервер видел только зашифрованные данные.
Предположим, я поместил базовые данные ecryptfs в:
/home/user/.Private
И я монтирую этот каталог по адресу:
/home/user/unlocked
Могу ли я обновить файлы в .Private (например, используя rsync) и ожидайте unlocked отразить изменения? Или это все испортит? Есть ли лучшие альтернативы для прямой синхронизации зашифрованных данных?
ОБНОВЛЕНИЕ, чтобы уточнить:
Я хочу когда-либо передавать на сервер только зашифрованные данные - серверу не доверяют. Итак, я хочу увидеть:
client <-- encrypted data --> server
Может быть несколько клиентов, обновляющих (расшифрованных) файлов; отсюда и желание живой синхронизации:
client1
\
\--- encrypted data --\
\
server
/
/--- encrypted data --/
/
client2
Итак, у клиента есть каталог, содержащий зашифрованные файлы, разбитый на части, как это делает 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 или что-то в этом роде замечает изменения и синхронизирует зашифрованные базовые файлы в .Private к серверу. Сервер, зная, что client2 также прослушивает, уведомляет client2, что он должен получить изменения.
Поэтому меня беспокоит следующее: если client2 вытягивает базовые фрагментированные файлы encryptfs в .Private, пока он монтируется в unlockedЯ подозреваю, что это вызовет проблемы, не так ли? Это потребует, чтобы client2 размонтировал unlocked перед синхронизацией, что разрушает всю идею "живой синхронизации".
Если да, то каковы хорошие альтернативные методы для эффективной синхронизации различий в зашифрованном дереве?
По словам Тайлера Хикса (одного из разработчиков eCryptfs), в настоящее время небезопасно изменять базовую файловую систему (нижняя файловая система в терминологии eCryptfs):
Было бы хорошо, если бы eCryptfs мог обнаруживать более низкие изменения данных файла и обновлять кеш, чтобы увидеть обновленный файл.
Даже если бы мы могли их обнаружить, как бы мы могли защитить их от грязных страниц eCryptfs? Как узнать, какие данные самые свежие?
К сожалению, прямые модификации нижней файловой системы просто не поддерживаются. Если модификация не проходит через точку монтирования eCryptfs, мы не можем ожидать, что узнаем об этом из-за архитектуры eCryptfs.
Источник: https://bugs.launchpad.net/bugs/689030
Чтобы обновить файлы в файловой системе ecryptfs, вам необходимо обновить их в точке монтирования - в зашифрованной файловой системе вам нужно будет обновить все сразу, поскольку в ней нет концепции файлов или каталогов - это просто большой кусок данных .
Да, вы можете использовать rsync для резервного копирования этих данных, но для чтения или записи определенного файла вам необходимо его смонтировать.
Вы можете монтировать его из разных мест (вероятно, лучше не пытаться делать это одновременно :-), так почему бы не использовать сценарий оболочки, который монтирует соответствующие файлы rsync и размонтирует их при каждом обновлении соответствующих файлов?
полезная информация Вот