Twórca systemu Linux, Linus Torvalds, ostro skrytykował twórców systemu plików Bcachefs po ich ogłoszeniu dotyczącym poprawki związanej z obsługą nazw katalogów w trybie niewrażliwym na wielkość liter. Jego zdaniem problem nie jest nowy, a deweloperzy najwyraźniej nie wyciągnęli wniosków z wcześniejszych błędów.

Na czym polega problem

Chodzi o specyfikę standardu Unicode, który jest bardzo elastyczny, ale zarazem złożony. Mechanizm tzw. case folding, czyli sprowadzania znaków do wspólnej wielkości liter, zawiera wiele wyjątków i sytuacji brzegowych, których nie sposób uwzględnić w pełni. W efekcie zachowanie aplikacji może odbiegać od tego, jak dany system plików interpretuje podobne znaki. Przykładowo: pewne symbole mogą wyglądać identycznie dla użytkownika, lecz mieć różną reprezentację bajtową – i odwrotnie.

Torvalds uważa, że próby „poprawnego” zaimplementowania niewrażliwości na wielkość liter tylko komplikują sprawę: deweloperzy zmuszeni są nadawać specjalne znaczenie konkretnym bajtom lub sekwencjom znaków, co prowadzi do nowych klas błędów i potencjalnych podatności. Może to wpływać także na bezpieczeństwo — kiedy aplikacja oczekuje konkretnej nazwy pliku, a system plików interpretuje ją inaczej.

Torvalds przypomniał, że czasy systemu FAT, w którym ignorowanie wielkości liter było standardem, dawno minęły. Podkreślił, że nowoczesne systemy plików powinny iść do przodu, a nie kopiować przestarzałe podejścia, które w obecnych warunkach częściej szkodzą, niż pomagają.

Fragment listu Torvaldsa do listy mailingowej jądra Linux 👇

Jedyny wniosek: deweloperzy systemów plików niczego się nie uczą. Obsługa nazw plików ignorująca wielkość liter to katastrofalny błąd, który nigdy nie powinien zostać zaimplementowany. Problem nie leży w braku testów — tylko w samej decyzji o wprowadzeniu takiego mechanizmu.
Później robi się jeszcze gorzej, gdy ktoś próbuje „zrobić to dobrze” — choć z definicji jest to niemożliwe. Kończy się na tym, że arbitralne bajty zyskują status „magicznych” wartości.
A przy okazji — testy są całkowicie wadliwe. Kiedy ostatnio je przeglądałem, nie obejmowały naprawdę interesujących przypadków — takich, które mogą prowadzić do podatności po stronie użytkownika.
Przykład? Aplikacja w przestrzeni użytkownika sprawdza, czy nazwa pliku nie pasuje do bezpiecznego wzorca. A system plików z ignorowaniem wielkości liter i tak pozwala to obejść — bo deweloperzy takich systemów zawsze robią coś w stylu ignorowania znaków niedrukowalnych. Finalnie „niewrażliwość na wielkość liter” staje się „niewrażliwością na Bóg wie co”.
Zobaczcie komity: 5c26d2f1d3f5 („unicode: Don’t special case ignorable code points”) oraz 231825b2e1ff („Revert ’unicode: Don’t special case ignorable code points’”)— i płaczcie.
Podpowiedź: ❤ i ❤️ to dwa różne znaki Unicode, różniące się wyłącznie tzw. ignorowanymi punktami kodowymi. I zgadnijcie co? Gdy niekompetentni deweloperzy chcą traktować je jako identyczne — przypadkowo sprawiają, że inne, być może kluczowe z punktu widzenia bezpieczeństwa, nazwy plików również są traktowane jako tożsame.
W rezultacie każda aplikacja, która filtruje ścieżki plików w celu uniknięcia określonych katalogów, może zostać oszukana i zmuszona do pracy z plikami, z którymi nie powinna mieć kontaktu. I nie — to nie jest egzotyczna anomalia, lecz codzienna praktyka: wiele aplikacji polega na takich zabezpieczeniach.
Cholera jasna. Obsługa nazw plików ignorująca wielkość liter to błąd. Fakt, że deweloperzy systemów plików nadal traktują to jak „funkcję”, jest dla mnie niezrozumiały. Jakby tak bardzo kochali archaiczny system FAT, że próbują go naśladować — tylko jeszcze gorzej.

Linus Torvalds

Co o tym sądzicie? Czy systemy plików niewrażliwe na wielkość liter rzeczywiście nie powinny istnieć, czy jednak mają jeszcze sens?