Jaki jest maksymalny dozwolony rozmiar nazwy pliku (i folderu) w eCryptfs?

44

Jestem nowym użytkownikiem eCryptfs i mam podstawowe pytanie, którego nigdzie nie mogłem znaleźć. Jestem zainteresowany korzystaniem z eCryptfs przez mój Synology NAS, który używa Linuksa.

Podczas próby zaszyfrowania mojego folderu (EXT4) za pomocą aplikacji szyfrującej Synology (eCryptfs) napotykam błędy, które wskazują, że długość mojej nazwy pliku nie może przekraczać 45 znaków (więc nie ma szyfrowania).

Jeśli limit tak naprawdę wynosi 45 znaków, eCryptfs może nie być użytecznym narzędziem dla większości.

Jaki jest maksymalny dozwolony rozmiar pliku podczas szyfrowania plików i folderów za pomocą eCryptfs? Czy Linux ma 255 znaków?

Fabry
źródło
6
Imho sposób, w jaki ecryptfs szyfruje nazwy plików, jest po prostu śmieszny. Najpierw rozdaje ponad 20 bajtów, przygotowując stały ciąg „ECRYPTFS_FNEK_ENCRYPTED”. do każdej nazwy pliku. Następnie dodaje zbyt wiele losowych bajtów, aby identyczne nazwy wyglądały inaczej. EncFS robi to w znacznie bardziej wydajny sposób.

Odpowiedzi:

70

Pełne ujawnienie: jestem jednym z autorów i aktualnym opiekunem narzędzi przestrzeni użytkownika eCryptfs.

Świetne pytanie!

Linux ma maksymalną długość pliku wynoszącą 255 znaków dla większości systemów plików (w tym EXT4) i maksymalną ścieżkę wynoszącą 4096 znaków.

eCryptfs to warstwowy system plików. Kumuluje się na innym systemie plików, takim jak EXT4, który jest faktycznie używany do zapisywania danych na dysku. eCryptfs zawsze szyfruje zawartość pliku, ale może opcjonalnie szyfrować (niejasne) nazwy plików (lub nie).

Jeśli nazwy plików nie są zaszyfrowane, możesz bezpiecznie napisać nazwy plików o długości do 255 znaków i zaszyfrować ich zawartość, ponieważ nazwy plików zapisane w dolnym systemie plików będą po prostu pasować. Chociaż osoba atakująca nie byłaby w stanie odczytać zawartości index.htmllub budget.xls, wiedziałaby, jakie nazwy plików istnieją. Może to (lub nie) wyciekać poufne informacje w zależności od przypadku użycia.

Jeśli nazwy plików są szyfrowane, sprawy stają się nieco bardziej skomplikowane. eCryptfs umieszcza trochę danych z przodu zaszyfrowanej nazwy pliku, aby mógł ostatecznie zidentyfikować zaszyfrowane nazwy plików. Również samo szyfrowanie wymaga „uzupełnienia” nazwy pliku.

Na przykład, mam zaszyfrowany plik ~/.bashrc. Ta nazwa pliku jest szyfrowana za pomocą mojego klucza, aby:

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

Oczywiście ta 7-znakowa nazwa pliku wymaga teraz więcej niż 7 znaków do zaszyfrowania. Empirycznie stwierdziliśmy, że nazwy plików znaków dłuższe niż 143 znaki zaczynają wymagać> 255 znaków do szyfrowania. Więc my (jako programiści eCryptfs) zwykle zalecamy ograniczenie nazw plików do ~ 140 znaków.

Teraz wszystko to powiedziało, Synology NAS jest komercyjnym produktem, który osadza i wykorzystuje eCryptfs i Linux do szyfrowania i zabezpieczania danych na urządzeniu. My (programiści eCryptfs) nie mamy nic wspólnego z Synology ani ich produktami, chociaż ogólnie cieszymy się, że eCryptfs są używane na wolności . Wydaje mi się, że ich zalecenie 45 znaków jest albo błędem typograficznym (z naszej rekomendacji 140 znaków), albo po prostu o wiele bardziej ostrożnym oszacowaniem.

Dustin Kirkland
źródło
Naprawdę chciałbym zobaczyć, system plików nakładek FUSE, który rozwiązuje swoje własne „zbyt długie nazwy plików” i spoczywa tylko proxy 1: 1 z podkładającym się systemem plików. Takie FUSE fs byłyby przydatne dla różnych systemów plików (ecryptfs, EncFS), podczas gdy dla obecnie obsługiwanych nazw plików nic by nie zmieniły. I znowu byłoby opcjonalne. - Moje życzenie: unix.stackexchange.com/q/283149/9689
Grzegorz
17
Ta odpowiedź nie jest do końca poprawna. Maksymalny rozmiar nazwy pliku to 255 bajtów lub znaków C / C ++. Ale maksymalna liczba znaków w nazwie pliku jest różna. W przypadku korzystania z UTF-8, który jest domyślny dla większości systemów, nazwa pliku może mieć od 63-255 znaków (zwanych również punktami kodowymi), jeśli używasz UTF-16, 63-127. Należy zauważyć, że 1 znak może być jednym lub więcej bajtami w przestrzeni pamięci i zależy od zestawu kodów, z którego korzysta użytkownik systemu.
Rahly,
Sugestia dla programisty: Podziel zaszyfrowane nazwy na podkatalogi, które są ukryte przed użytkownikiem końcowym, aby uzyskać niezbędną długość, potencjalnie nawet przekraczając maksymalny limit długości nazwy linuksa, jeśli wymaga tego zewnętrzny system plików. Pojedynczy plik lub katalog ma postać „ENCRYPTFS-01-OF-04 [.....] / ENCRYPTFS-02-OF-04 [.....] / ENCRYPTFS-03-OF-04 [..... ] / ENCRYPTFS-04-OF-04 [.....] "- Linux btrfs, ext1-4 i inne nie mają zdefiniowanej maksymalnej głębokości katalogu, więc system plików może obsługiwać rozwijanie nazw plików i katalogów w wielu nienaświetlonych podkatalogach, takich jak ten .
Dale Mahalko,
1
Moją sugestią byłoby przechowywanie wszelkich metadanych, które przechowujesz w xattrs zamiast w nazwie pliku. : |
Trejkaz
1
Mówisz, że eCryptfs „może opcjonalnie szyfrować (niejasne) nazwy plików (lub nie)”. Jak wyłączyć szyfrowanie nazw plików, aby odzyskać pełne nazwy plików o wielkości 255 znaków zamiast ograniczania do 143 znaków? Nawiasem mówiąc, uważam, że sposób, w jaki zainstalowałem eCryptfs, polegał na zaznaczeniu pola lub cokolwiek „Encrypted home directory” podczas procesu instalacji Ubuntu.
Gabriel Staples
11

Ten wątek jest bardzo interesujący, ponieważ zastanawiałem się nad tym samym. Mogę żyć z koniecznością zmiany nazwy 20 plików na 50 000, jeśli nazwy plików muszą mieć 140 znaków lub mniej, ale 45 lub mniej nie jest możliwe (w mojej sytuacji), ponieważ wymagałoby to zmiany nazwy zbyt wielu plików.

Zadałem dokładnie to samo pytanie bezpośrednio Synology (wskazując nawet na niniejszy artykuł), a ich odpowiedź była interesująca: „Limit nazwy pliku zaszyfrowanego udziału wynosi 143 bajty. Może mieć maksymalnie 140 znaków łacińskich lub 45 CJK (chiński , Japońskim i koreańskim). ”

Po tej odpowiedzi sam wykonałem więcej testów, testując pliki o rozmiarze 45, 46, 140, 143 i 144 znaków. Moje testy pokazują, że pliki do 143 znaków (nie bajtów, w przeciwieństwie do tego, co powiedział mi Synology) zostaną zaszyfrowane, ale pliki zawierające 144 znaki ZAPOBIEGAJĄ folderowi, który ma zostać zaszyfrowany. Jednak KOMUNIKAT O BŁĘDZIE, który otrzymuję z mojego serwera NAS, to, że nazwa pliku musi mieć mniej niż 45 znaków (podczas gdy rzeczywistość jest taka, że ​​powinna mieć mniej niż 144 znaki).

Nie przeprowadzałem testów ze znakami CJK ... Ale dla każdego, kto to czyta, wydaje się, że wszystko w porządku do 143 znaków, pomimo tego, co mówi system.

sdasdrewr
źródło
7

Chciałbym wyjaśnić, że linux ma limit 255 bajtów na nazwę pliku, a nie 255 znaków. Jest to znacząca różnica i jeśli użyjesz np. Kodowania UTF-8, możesz otrzymać nazwy plików o długości do 100 znaków.

Richard Jelinek
źródło
1
63 to maksimum, jeśli każdy znak używa maksymalnego kodowania 4 bajtów na punkt kodowy. To samo dotyczy wszystkich schematów UTF (UTF-16 i UTF-32)
Rahly,
@Rahly To jednak może się ostatecznie zmienić. Zanim maksymalny prawidłowy punkt kodowy Unicode został zredukowany, aby U+10FFFFspełnić ograniczenia UCS-2 (w zasadzie UTF-16 bez par zastępczych), UTF-8 może wymagać do 6 bajtów do przedstawienia 32-bitowego punktu kodowego z powodu sposobu kodowania „początek znaku” i „kontynuacja znaku”, aby zapewnić, że synchronizacja analizatora składni może zostać ponownie uzyskana bez względu na to, gdzie rozpoczyna się analizowanie w strumieniu bajtów. Zawsze istnieje możliwość, że ostatecznie zdecydują się cofnąć tę decyzję, ponieważ brakuje im nieprzypisanych punktów kodu.
ssokolow
1
Ale bardzo mało prawdopodobne, chyba że zaczną dodawać postacie jak szalone. Od wersji 8.0 przypisanych jest tylko 120 tys. Dodali ~ 8k znaków w tej iteracji. Jeśli tak będzie, konieczne będzie rozszerzenie wersji ~ 106.
Rahly,
I myślę, że najpierw musieliby zabić Windows również JavaScript, ponieważ obaj polegają na UTF-16. (Być może uda się to jednak naprawić w przypadku JavaScript?)
SamB
1

Długość pliku ecrypt była dla mnie problemem tylko dlatego, że potrzebowałem konkretnego poddrzewa mojego katalogu domowego do obsługi długich nazw plików, i ostatecznie zdałem sobie sprawę, że mogę po prostu stworzyć system plików wewnątrz pliku i zamontować go:

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

Prawdopodobnie występują z tym różnego rodzaju problemy z wydajnością, ale to wystarcza w moim przypadku, w którym pliki to tylko wyniki testów okresowo tworzone dla moich własnych lokalnych celów.

Moi koledzy umieścili swój obraz w / tmp - dane testowe nie są szczególnie poufne: chcemy przede wszystkim zabezpieczyć nasz kod źródłowy, a nie wyniki testów.

android.weasel
źródło