Каков максимально допустимый размер имени файла (и папки) с eCryptfs?

44

Я новый пользователь eCryptfs, и у меня есть очень простой вопрос, который я нигде не смог найти. Я заинтересован в использовании eCryptfs через NAS-устройство Synology, использующее Linux.

При попытке зашифровать мою папку (EXT4) с помощью приложения шифрования Synology (eCryptfs) я сталкиваюсь с ошибками, в которых утверждается, что длина моего имени файла не может превышать 45 символов (поэтому шифрование отсутствует).

Если ограничение на самом деле составляет 45 символов, eCryptfs не может быть полезным инструментом для большинства.

Каков максимально допустимый размер имени файла при шифровании файлов и папок с помощью eCryptfs? Является ли Linux 255 символов?

filenames ecryptfs synology Фабри
источник
6
Имхо способ, которым ecryptfs зашифровывает имена файлов, просто нелеп. Сначала он выдает более 20 байтов, добавляя фиксированную строку «ECRYPTFS_FNEK_ENCRYPTED». к каждому имени файла. Затем он добавляет слишком много случайных байтов, чтобы идентичные имена выглядели по-разному. EncFS делает это гораздо более эффективным способом.

Ответы:

70

Полное раскрытие: я один из авторов и текущий сопровождающий утилит eCryptfs для пользователей.

Отличный вопрос!

Linux имеет максимальную длину имени файла 255 символов для большинства файловых систем (включая EXT4) и максимальный путь 4096 символов.

eCryptfs - это многоуровневая файловая система. Он располагается поверх другой файловой системы, такой как EXT4, которая фактически используется для записи данных на диск. eCryptfs всегда шифрует содержимое файла, но при желании может шифровать (скрывать) имена файлов (или нет).

Если имена файлов не зашифрованы, вы можете безопасно написать имена файлов длиной до 255 символов и зашифровать их содержимое, так как имена файлов, записанные в нижнюю файловую систему, будут просто совпадать. Хотя злоумышленник не сможет прочитать содержимое index.htmlили budget.xls, он будет знать, какие имена файлов существуют. Это может (или не может) утечь конфиденциальную информацию в зависимости от вашего варианта использования.

Если имена файлов зашифрованы, все становится немного сложнее. eCryptfs добавляет немного данных в начало зашифрованного имени файла, так что он может окончательно идентифицировать зашифрованные имена файлов. Кроме того, само шифрование включает «заполнение» имени файла.

Например, у меня есть зашифрованный файл ~/.bashrc. Это имя файла зашифровано с использованием моего ключа для:

/home/kirkland/.Private/ECRYPTFS_FNEK_ENCRYPTED.dWek2i3.WxXtwxzQdkM23hiYK757lNI7Ydf0xqZ1LpDovrdnruDb1-5l67.EU--

Очевидно, что это 7-символьное имя файла теперь требует более 7 символов для шифрования. Опытным путем мы обнаружили, что имена файлов с именами длиннее 143 символов начинают требовать> 255 символов для шифрования. Поэтому мы (как разработчики eCryptfs), как правило, рекомендуем вам ограничить имена файлов до ~ 140 символов.

Теперь все это говорит о том, что Synology NAS - это коммерческий продукт, который встраивает и использует eCryptfs и Linux для шифрования и защиты данных на устройстве. Мы (ведущие разработчики eCryptfs) не имеем ничего общего с Synology или их продуктами, хотя, как правило, мы рады видеть, что eCryptfs используются в дикой природе . Мне кажется, что их рекомендация в 45 символов является либо опечаткой (из нашей 140-символьной рекомендации), либо просто более консервативной оценкой.

Дастин Киркланд
источник
Мне бы очень хотелось, чтобы FUSE наложил файловую систему, которая разрешает свои собственные "слишком длинные имена файлов", и оставил только прокси 1: 1 с лежащей в основе файловой системой. Такие FUSE fs будут полезны для разных файловых систем (ecryptfs, EncFS), в то время как для поддерживаемых в настоящее время имен файлов ничего не изменится. И снова будет необязательным. - Мое желание: unix.stackexchange.com/q/283149/9689
Гжегож Вежовецкий,
17
Этот ответ не совсем правильный. Максимальный размер имени файла составляет 255 байт или типы символов C / C ++. Но максимальное количество символов в имени файла варьируется. При использовании UTF-8, который используется по умолчанию для большинства систем, имя файла может быть в пределах 63–255 символов (или кодовых точек), если используется UTF-16, 63–127. Важно отметить, что 1 символ может быть одним или несколькими байтами в пространстве памяти и зависит от кодового набора, который использует пользователь системы.
Рахли
Предложение для разработчика: разделите зашифрованные имена по подкаталогам, которые скрыты от конечного пользователя, чтобы получить необходимую длину, потенциально даже превышающую предел максимальной длины имени linux, если это требуется внешней файловой системе. Один файл или каталог становится "ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "- Linux btrfs, ext1-4 и другие не имеют максимальной заданной глубины каталогов, поэтому файловая система может обрабатывать расширяющиеся имена файлов и каталогов в нескольких неэкспонированных подкаталогах, как это ,
Дейл Махалко
1
Мое предложение состояло бы в том, чтобы хранить любые метаданные, которые вы храните в xattrs, а не в имени файла. : |
Trejkaz
1
Вы говорите, что eCryptfs «может шифровать (скрывать) имена файлов (или нет)». Как отключить шифрование имени файла, чтобы можно было вернуть полные имена файлов из 255 символов вместо ограничения в 143 символа? Я полагаю, что способ установки eCryptfs был, между прочим, установленным флажком или что-то вроде «Зашифрованный домашний каталог» во время процесса установки Ubuntu.
Габриэль Стейплс
11

Эта тема очень интересная, потому что мне было интересно то же самое. Я могу смириться с необходимостью переименовать 20 файлов из 50 000, если имена файлов должны быть 140 символов или менее, но 45 или менее не представляется возможным (в моей ситуации), потому что это потребовало бы, чтобы я переименовал слишком много файлов.

Я задал точно такой же вопрос непосредственно Synology (даже указав им на настоящую статью), и их ответ был интересным: «Ограничение имени файла зашифрованного общего ресурса составляет 143 байта. Это может быть до 140 символов чистой латиницы или 45 CJK (китайский язык) , Японские и корейские) персонажи. "

После этого ответа я провел больше тестирований, тестируя файлы размером 45, 46, 140, 143 и 144 символа. Мои тесты показывают, что файлы длиной до 143 символов (не байты, вопреки тому, что сказал мне Synology) будут зашифрованы, но файлы с 144 символами предотвратят зашифрование папки. Тем не менее, СООБЩЕНИЕ ОБ ОШИБКЕ, которое я получаю от моего NAS, состоит в том, что имя файла должно быть менее 45 символов (тогда как реальность такова, что оно должно быть менее 144 символов).

Я не делал тесты с символами CJK ... Но всем, кто читает это, кажется, что у вас все в порядке до 143 символов, несмотря на то, что система говорит вам.

sdasdrewr
источник
7

Я хотел бы уточнить, что Linux имеет ограничение 255 байт на имя файла, а не 255 символов. Это существенная разница, и если вы используете, например, кодировку UTF-8, вы можете получить имена файлов не более 100 символов.

Ричард Елинек
источник
1
63 - это максимум, если каждый символ использует максимальную кодировку 4 байта на кодовую точку. Это то же самое для любой из схем UTF (UTF-16 и UTF-32)
Рахли
@Rahly Это может в конечном итоге измениться, хотя. До того, как максимально допустимая кодовая точка Unicode была уменьшена до U+10FFFFсоответствия ограничениям UCS-2 (в основном UTF-16 без суррогатных пар), UTF-8 могло потребоваться до 6 байтов для представления 32-битной кодовой точки из-за того, как он кодирует «начало символа» и «продолжение символа», чтобы гарантировать, что синхронизация синтаксического анализатора может быть восстановлена ​​независимо от того, где вы начинаете анализ в потоке байтов. Всегда есть вероятность, что они в конечном итоге решат отменить это решение, потому что у них заканчиваются неназначенные кодовые точки.
ssokolow
1
Но крайне маловероятно, если только они не начнут добавлять персонажей вроде сумасшедших. Начиная с U8.0, назначено только 120 КБ. Они добавили ~ 8 тыс. Символов в этой итерации. Если они продолжат в том же духе, его нужно будет расширить до версии ~ 106.
Рахли
И я думаю, что сначала им придется убить Windows и JavaScript, так как они оба используют UTF-16. ( Возможно, это можно исправить в случае JavaScript?)
SamB
1

Длина имени файла ecrypt была для меня только проблемой, потому что мне нужно было определенное поддерево моего домашнего каталога для поддержки длинных имен файлов, и в конце концов я понял, что могу просто создать файловую систему внутри файла и смонтировать это:

dd if=/dev/zero of=/home/me/.some.img bs=1024 count=1024
mkfs.ext3 /home/me/.some.img
chmod 777 /home/me/longfilenames
sudo mount /home/me/.some.img /home/me/longfilenames

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

Мои коллеги поместили свое изображение в / tmp - данные теста не являются особо конфиденциальными: мы в основном хотим защитить наш исходный код, а не результаты нашего теста.

android.weasel
источник