Сквозной метод уровня ядра для изменения хэшей файлов

266
Hamy

Я ищу любой механизм уровня ядра, который является сквозным и изменяет хэши файлов, либо шифруя содержимое файла, либо добавляя данные. Наиболее очевидным решением является шифрование, но я не могу найти подходящих (например, полностью только для ядра, без ecryptfs, без FUSE и т. Д.) Методов шифрования.

В частности, у меня есть большое количество файлов, /fooкоторые я хотел бы также отображать /foobarлюбым способом, который запутывает исходный MD5 файлов, без дублирования необработанных данных. Меня не волнует, будут ли файлы в /foobarних бесполезными из-за дополнений - я с удовольствием добавляю несколько случайных байтов к каждому файлу и позволяю разбить многие форматы файлов, но я не знаю, как это сделать с некоторыми вид крепления

0

1 ответ на вопрос

1
grawity

Если вы ищете пользовательский оверлей файловой системы, FUSE - правильное направление. Существуют различные пользовательские файловые системы, написанные с использованием FUSE (sshfs, ntfs-3g, wikipediafs ...), включая простые оверлеи, такие как bindfs .

Можно взять исходный код bindfs и изменить его, скажем, на XOR первого байта с некоторыми случайными данными всякий раз, когда он обрабатывает операцию чтения.

Для варианта чистого ядра, вы можете изменить overlayfsили unionfsдрайвер аналогичным образом.

Другой вариант - взять Samba, написать модуль Samba vfs для поврежденных файлов, открыть общий доступ к исходному каталогу и смонтировать его на той же машине, используя cifsдрайвер Linux . (То же самое возможно и с помощью 9pдрайвера и u9fsдемона, или с nfsдрайвером и каким-либо другим демоном NFS-сервера.)


Если вас не интересует содержимое, создайте разреженные файлы нужного размера; они вообще не будут занимать места:

$ truncate -s 1G largefile $ du -h --apparent largefile 1G largefile $ du -h largefile 0 largefile 

Зациклите дерево так:

cd /foo find -type d | while read -r file; do mkdir -p "/foobar/$file" done find -type f | while read -r file; do truncate -r "$file" "/foobar/$file" done 
Мне нужен механизм уровня ядра, который исключает любое использование FUSE: - / иначе это было бы здорово :-P Hamy 9 лет назад 0
О, разреженные файлы - отличная идея, но я должен уточнить, что я * забочусь * о сохранении содержимого, я просто хочу, чтобы хэш отличался. Я обновлю свой пост, извините за путаницу Hamy 9 лет назад 0
@Hamy: Не могли бы вы также объяснить, почему именно механизм уровня ядра требуется специально и что делает FUSE непригодным для использования? grawity 9 лет назад 0
Конечно, только ядро ​​является требованием CrashPlan. Он, очевидно, не может должным образом оценивать файлы (такие как зашифрованные файлы), если изменения не сделаны в ядре и поэтому полностью невидимы для него. Требование только для ядра полностью исключает возможность использования FUSE, потому что (AFAIK) каждая отдельная файловая система на основе FUSE выполняется в пользовательском пространстве, тогда как сам fuse является частью, выполняемой в ядре. Hamy 9 лет назад 0
К вашему сведению, я еще не пробовал систему на базе FUSE, но я вижу обнадеживающие сообщения о том, что sshfs действительно может использоваться с crashplan, по адресу http://askubuntu.com/questions/337305/back-up-sshfs-network-drive-to -Крашплан, так что я прямо сейчас даю ему шанс. Возможно, ответ был очевиден все время ... * скрестив пальцы * Hamy 9 лет назад 0
@Hamy: «контроллер» FUSE находится в пользовательском пространстве, но драйвер файловой системы встроен в ядро, и, если контроллер реализует необходимые функции, он _indistinguishable_ от любой другой файловой системы ко всем другим программам пользовательского пространства. И, как показано в посте Ask Ubuntu, проблема не в том, что FUSE является полупользовательским пространством, а в том, что FUSE по умолчанию запрещает доступ другим пользователям, кроме mounter (`-o allow_other`). grawity 9 лет назад 0
Вы правы, я неправильно понял, что CrashPlan имел в виду под «только ядром», когда ecryptfs не работал из коробки. Только что протестировал файловую систему на основе FUSE, и она отлично работала, так что спасибо большое за то, что заставили меня взглянуть на FUSE еще раз! Hamy 9 лет назад 0

Похожие вопросы