Kernel Traffic #143 For 26 Nov 2001

Komentarze/problemy z NTFSem w związku z proponowanym EA/ACL API:

Sądzę, że API jest dobre dla rozszerzonych atrybutów, co do tego nie mam wątpliwości. Jeśli kiedykolwiek zajmiemy się implementacją EA (extended attributes) w NTFS, to z przyjemnością będę używał tego API. W pełni odpowiada ono wymaganiom rozszerzonych atrybutów NTFS. Jedyną rzeczą, jaką chciałbym dodać do tego API jest to, że nazwy rozszerzonych atrybutów muszą móc mieć różne przestrzenie nazw. Na przykład, jestem pewien, że nazwa EA w NTFS nie może zawierać każdego znaku i na pewno nie może mieć nazwy dowolnej długości... To jest coś, co powino być wzięte pod uwagę. Zdefiniowane muszą być przynajmniej zwracane wartości błędów "EILSEQ" (zła przestrzeñ nazw) i "ENAMETOOLONG" (samo się tłumaczy).

Co do ACLi nie jestem już tak pozytywnie nastawiony:

Podejrzewam, że prawdziwym problemem jest to, że bezpieczeñstwo NTFS nie przekłada się dobrze na model bezpieczeñstwa w systemach Unix/Linux, gdyż model NTFS ma znacznie więcej cech.

Jeśli zadajesz pytanie, czy NTFS może działać z proponowanym API, odpowiedź brzmi: tak; może obsługiwać wszystkie jego cechy, ale nie jest to prawdą w drugą stronę...

Szczególne problemy:

• Proponowane API umieszcza ACLe wewnątrz rozszerzonych atrybutów (EA). W systemie NTFS ACLe nie mają nic wspólnego z rozszerzonymi atrybutami. Są to dwie całkowicie różne rzeczy. Podejrzewam, że mogą być połączone w jedno API, a sterownik NTFS musiałby coś parsować i decydować, czy w danej sytuacji należy operować na ACLach czy na EA. Ale byłoby to bolesne, głównie dlatego, że mogłoby to dać parę sposobów na nadużycia w systemie, zależnie od tego, jak dokładnie zostałoby to zaimplementowane.

• ACLe w NTFS są _dużo_ bardziej złożone niż te zasugerowane. Zatem odwzorowanie jednych na drugie jest możliwe tylko wtedy, gdy tworzone są nowe pliki. W trakcie czytania/pisania istniejących ACLi sporo informacji zostanie zgubionych.

  Co więcej, każdy i-węzeł ma właściciela ,,użytkownika'' i grupę ,,właściciela'' oraz dwa typy ACLi: systemowe (SACL) oraz ,,normalne''(DACL).

  Te cztery rzeczy są przechowywane w pojedynczym deksryptorze bezpieczeñstwa. Część z nich jest opcjonalna, albo może być dziedziczona z i-węzła będącego rodzicem, lub może być domyślna. - To tak naprawdę łamie założenia obecnego API, które mówi, że pliki nie mogą dziedziczyć, ani mieć domyślnych ACLi. W NTFS mogą.

  Uprawnienia w NTFS to, tak naprawdę, nie tylko RWX, są one dużo bardziej ziarniste (opisane 32-bitowo, posłuż się URLem poniżej żeby uzyskać listę wszystkich zdefiniowanych wartości), a niektóre z nich nawet determinują prawa dostępu do rozszerzonych atrybutów, więc nie trzeba nawet mówić, że stanowi to problem, jeśli potraktujemy ACLe jako EA...

• NTFS nie przechowuje uidów, ale Identyfikatory Bezpieczeñstwa (te 'SID', a nie te 'Security_ID' -- są to oddzielne rzeczy w NTFS. Nie zakręciliście się jeszcze? Bo ja owszem...), więc mapowanie musiałoby występować pomiędzy NTFSowymi SID a Linuksowymi UIDami. Samba również tego wymaga (i to robi, z tego co wiem), ale jest to raczej problem NTFS, a nie Linuksowego ACL API.

Wszystko, co związane jest z bezpieczeñstwem NTFS, można znaleźć pod podanym niżej adresem - po prostu poszukaj IDENTIFIER_AUTHORITY i poczytaj dalej... wszystkie struktury związane z bezpieczeñstwem są tam zdefiniowane, jest tam też kilka komentarzy.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/linux-ntfs/ntfs-driver-tng/linux/
include/linux/ntfs_layout.h?rev=1.11&content-type=text/vnd.viewcvs-markup

Możesz też przeczytać dokumentację NTFS na SF, ale zauważ, że nie jest tak kompletna jak plik nagłówkowy podany powyżej, może być za to łatwiejsza do zrozumienia. Odnośnik z opisem deskryptora bezpieczeñstwa to:

http://linux-ntfs.sourceforge.net/ntfs/attributes/security_descriptor.html

Andreas i ja oglądaliśmy wiele różnych mechanizmów VFS dla roszerzonych atrybutów, załączyłem poniżej kod jednego z nich; podoba nam się, że udało się uzyskać informację zwrotną także tutaj.

Wystartowaliśmy z najprostszym mechanizmem, przekazując bezpośrednio wszystko w dół do systemu plików. Bawiłem się potem różnymi sposobami oddzielania różnych operacji i w ten sposób przekazywania wszystkiego do systmu plików (zobacz łatkę), by dać interfejsowi dokładniejszą definicję. Oryginalny mechanizm Andreasa był bardzo podobny do tego, z wyjątkiem używania NULLi w niektórych polach, zamiast wyraźnie sprecyzowanych flag, rozróżniających podobne operacje - to jest inne podejście.

Jeszcze innym sposobem byłoby trzymanie wektora ea_operations oddzielnie od inode_operations ze wskaźnikiem do ea_operations w strukturze i-węzła, wyliczając wszystkie operacje EA i robić je oddzielnie, z flagami (w łatce poniżej) razem.

Życie Ci zbrzydło? Nie masz nic do roboty? Napisz system plików!

Co to jest FUSE?

FUSE (Filesystem in USErspace) dostarcza programom działającym w trybie użytkownika prostego interfejsu do eksportowania wirtualnego systemu plików do jądra Linuksa. Celem FUSE jest także dostarczenie nieuprzywilejowanym użytkownikom bezpiecznej metody tworzenia i montowania implementacji systemu plików.

Jest przecież NFS, czy CODA. Po co FUSE?

Tak, zarówno NFS, jak i CODA, umożliwiają tworzenie systemów plików w trybie użytkownika. Ale żadne z nich nie zostało zaprojektowane w tym celu. Projekt FUSE różni się od powyższych następującymi rzeczami:

• Możliwość udostępnienia _bardzo_ prostego interfejsu biblioteki w trybie użytkownika.
• Wąska warstwa w jądrze. Minimalne cache'owanie, przewidywalne zachowanie.
• Komunikacja nie odbywa się poprzez sieć i jest zoptymalizowana dla przesyłania danych lokalnie.
• Bezpieczne środowisko, nawet jeśli klient w trybie użytkownika nie jest kooperatywny.

Wszystko fajnie, ale czy to działa?

Przetestowałem FUSE przy użyciu prostego programu 'loopback', oraz używając AVFS (http://www.inf.bme.hu/~mszeredi/avfs/), dla którego zaprojektowano FUSE. To nie znaczy, że nie ma w nim błędów, ale to dobry znak...

Czy jest to dostępne?

Tak. Można ściągnąć z

http://sourceforge.net/projects/avf

Jak można to zainstalować?

FUSE obecnie działa tylko na jądrach 2.4.X. Instalacja wymaga źródeł jądra. Jądro nie musi być łatane lub rekompilowane: część FUSE znajdująca się w jądrze jest instalowana jako moduł. Moduł FUSE jest bezpieczny dla SMP.

Jest także łata na jądro (dla jąder 2.4.12 i nowszych), zawarta w dystrybucji, która sprawia, że montowanie przez nieuprzywilejowanego użytkownika jest bezpieczne.

Komentarze na temat projektu, implementacji i stanu mojego umysłu są mile widziane.

Zrobiłem parę testów wydajności z FUSE i okazało się, że przepustowość wynosi około 60MB/s na Celeronie/360 zarówno dla odczytu, jak i zapisu. Ale tak, to rzeczywiście zawiera dwie zmiany kontekstu i parę copy_to_user/copy_from_user dla każdej strony.

Sądzę, że przy takiej prędkości, brak cache'owania w jądrze nie jest aż takim wielkim problemem, a _cholernie_ upraszcza to sprawy.

Gdy insmod wykryje moduł, nie będący na licencji zgodnej z GPL, z nierozwiązanymi symbolami to, obecnie, wypisuje:

Note: modules without a GPL compatible license cannot use GPLONLY_ symbols (Uwaga: moduły nie posiadające licencji zgodnej z GPL nie mogą używać symboli GPLONLY_)

Myślałem, że ta wskazówka mówi sama za siebie, ale oczywiście nie jest ona jasna. Nigdy nie należy przeceniać umiejętności luzerów w zakresie niewłaściwej interpretacji informacji. insmod 2.4.12 powie:

Hint: You are trying to load a module without a GPL compatible license and it has unresolved symbols. The module may be trying to access GPLONLY symbols but the problem is more likely to be a coding or user error. Contact the module supplier for assistance. (Wskazówka: Próbujesz załadować moduł nie posiadający licencji zgodnej z GPL i ma on nierozwiązane symbole. Moduł być może stara się użyć symboli GPLONLY ale najprawdopodobniej problemem jest błąd w kodzie lub błąd użytkownika. Aby uzyskać pomoc skonaktuj się z dostawcą modułu.)

Czy ktoś uważa, że taki komunikat może być źle zrozumiany przez kogokolwiek posiadającego ,,inteligencję'' normalnego użytkownika Windozy?

Tak, sądzę, że to może być źle zrozumiane, i, co być może ważniejsze, wciąż wskazuje użytkownikowi problem z GPLONLY, gdy najprawdopodobniej jest to niezgodność wersji. Lepiej mogłoby być:

Wskazówka: Próbujesz załadować moduł z nierozwiązanymi symbolami. Te symbole mogą nie być eksportowane przez tę wersję jądra (być może występują niezgodności wersji), albo są one wyeksportowane GPLONLY (w tym wypadku nie są one udostępniane modułom, które nie mają licencji zgodnej z GPL). W obu przypadkach skontaktuj się z dostawcą modułu, by uzyskać pomoc.

nie do koñca jest to prawdą. Użyj albo jądra z RH, albo jądra -ac, albo dołączonej łaty (dla 2.4.15-pre4). Potem ustaw /proc/sys/wm/max-readahead na 511 lub 1023 (potęga 2 minus 1)

to powinno Ci pozwolić na uzyskanie dostatecznie dużego we/wy przy odczycie strumieniowym, tak aby uzyskać to, o co Ci chodzi.

Dostępny jest już mconfig w wersji 0.20.

Mconfig jest narzędziem do konfiguracji jądra linuksa, podobnym do make {menu,x,}config, lecz napisanym w C, oraz przy użyciu poprawnego parsera yacc.

Odkąd Michael Elizabeth Chastain wypuścił ostatnią wersję, 0.18, wprowadzono następujące zmiany:

• przejście na autoconf/automake.
• budowanie trybu 'menu' tylko, gdy dostępne są curses.
• dodanie strony man (BARDZO proste).
• dodanie pliku .spec do budowania pakietów RPM.
• tekst pomocy przesunięty ze źródeł do osobnego pliku.
• zaimplementowane tryby 'text' i 'old'.
• zaimplementowane słowo 'dep_mbool'.
• mniej restrykcyjne sprawdzanie błędów -- opłakujcie.

Ta wersja dostępna jest jako archiwum tar.gz/tar.bz tutaj:

ftp://ftp.kernel.org/pub/linux/kernel/people/hch/mconfig/

ftp://ftp.opengfs.org/pub/opengfs/0.0.91/opengfs-0.0.91.tar.gz

ftp://ftp.opengfs.org/pub/opengfs/0.0.91/opengfs-0.0.91-1.src.rpm

Christoph, czy mógłbyś wyjaśnić, dlaczego zostaje to dodane teraz, i jak wygląda w porównaniu z CML1 i/lub CML2?

Dla kbuild 2.[45] całkowicie obojętnym jest, w jaki sposób budowane są .config i autoconf.h; wymaga on tylko, aby .config był wewnętrznie spójny, zanim kbuild wejdzie w fazę głównego budowania. Nie obchodzi mnie, jak budowany jest .config, ale chciałbym zrozumieć, dlaczego rozwijana jest kolejna wersja CML.

Wysłałem kolejną łatę. Z jakiegoś powodu poprzednia zawierała również pewne poprawki do NTFS. Poprawiłem. Łata, która znajduje się pod adresem ftp.timpanogas.org:/nwfs/nwfs-2.4.15-pre5-4.gz, wprowadza do Linuksowego jądra 2.4.15-pre5 system plików NWFS (NetWare File System).

Łatka została wysłana Linusowi w celu rozważenia możliwości dołączenia jej do jądra Linuksa.

Panie Jeff V. Merkey,

Jak można zauważyć z powyższego cytatu, sporo niepokoju wiąże się z naturą i stanem kodu, który wysłał Pan w celu dołączenia do głównego drzewa jądra Linuksa. Ponieważ znam od podszewki Pañską firmę oraz sposób powstawania kodu, o którym mówimy, następujące wymagania muszą zostać spełnione przez Pana oraz Pañskiego Dyrektora Zarządzającego (ang: general council), Pana Andrew McCullougha.

Następujące sprawy muszą zostać uregulowane w oficjalnym piśmie, które powinienem przejrzeć ja, każdy wyznaczony Dyrektor Zarządzający, każdy członek ekipy rozwijającej rdzeñ jądra Linuksa i/lub ich pracodawcy. Może to dotyczyć również innych organizacji, gdzie kod ten będzie dystrybuowany.

Data i czas rozpoczęcia prac nad Systemem Plików NetWare (zaliczającego się do naśladowców) (zwanym dalej NWFS), który ma być bezpośrednim substytutem infrastruktury systemu, nad którym pracował Pan jako pierwotny autor NWFS z Novella 4.XX, przez okres zatrudnienia jako ,,Drugi po Bogu'', oraz ,,Główny Programista''.

Na podstawie ogólnej znajomości Prawa Stanu Utah, musi Pan określić prawnie datę pierwszego ujawnienia Pañskiej wersji dostępu/uaktualniania natywnych środowisk przechowywania danych, mających zainstalowany komercyjny produkt, znany wszystkim jako System Operacyjny Novell (Novell OS, NOS).

Od tego momentu, musi Pan nakreślić wszystkie kroki podjęte przez Pañskiego poprzedniego pracodawcę, firmę Novell, które mogą być określone jako zgodne z prawem próby spełnienia warunków dwuletniego okresu, podczas którego można rościć pretensję do TRG. Jeśli okres ten minął, a Novell nie podjął żadnych działañ -- wtedy, zgodnie z tym, co wiem, przedstawione przez Pana materiały mogą być spokojnie przeglądane. Jednak, jeżeli znajdą się tam jakiekolwiek odniesienia czy możliwości dołączenia Rozszerzonych Usług Katalogów Novell (Novell Extended Directory Services; E-Directory), będzie Pan musiał usunąć taki materiał.

Należy powtórzyć powyższe czynności, biorąc pod uwagę wszystkie inne środowiska, które mogą podlegać jakimkolwiek innym prawom, nie wymienionym powyżej.

Znalazłem się teraz w niepewnym położeniu; jednakże, dopóki wyżej wymienione problemy nie zostaną zweryfikowane i rozwiązane, nie powinien się Pan spodziewać, że Pañska praca nad tym projektem zostanie zaakceptowana w chwili obecnej.

Jeśli byłby Pan w stanie rozwiać wątpliwości moje, oraz innych członków zespołu rozwijającego jądro, wybranych przez Linusa Torvaldsa; zniknąłby mój niepokój i zasugerowałbym generalny przegląd w celu zaadoptowania kodu. Powinien też Pan wiedzieć, że jestem tylko w stanie czynić sugestie, oraz uwypuklać niepokojące rzeczy. Ostateczna decyzja jest wyłączną odpowiedzialnością Linusa Torvaldsa.

Szanowny Panie Hedrick,

Zastosuję się do dyrektyw Reprezentantów Społeczności Linuksowej i każę Panu McCulloughowi przygotować żądaną dokumentację.

NWFS jest, czego jest Pan świadomy, całkowicie przepisaną wersją Natywnego Systemu Plików Novella. TRG posiada systemy sprawdzania wersji, które śledziły powstawanie tego kodu od początku jego istnienia; nie zostały użyte ani Źródła Novella, ani żadne poufne informacje, czy tajemnice handlowe Novella, w formie określonej przez UTSA (Uniform Trade Secrets Act).

Materiały te zostaną ukoñczone i przekazane Panu nie później, niż w tę środę. Nie zostaną opublikowane na LKML, ponieważ są dziełem prawnika. Jesteśmy zaszczyceni możnością zaoferowania naszej technologii Społeczności Linuksowej, oraz możliwością przyczynienia się do nieprzeciętnych wysiłków Linusa Torvaldsa i innych członków Społeczności Linuksowej, którzy odnieśli wielki sukces.

Do środy dostarczę tę dokumentację. Andrew będzie do Pañskiej telefonicznej dyspozycji, jeżeli będzie Pan chciał omówić jakiekolwiek konkrety. Jego numer telefonu to 801-222-9635.

Dobrze wiedzieć. Rozwijam nowy sterownik NTFS -- NTFS TNG. Póki co, potrafi tylko czytać, ale jest prawie kompletny, jeśli chodzi o podstawowe umiejętności odczytywania. Tzn: teraz działa. Jedyną rzeczą, której mu brakuje, to możliwość listowania atrybutów, ale pracuję nad tym. (-;

Jeżeli Ty, lub ktokolwiek inny oczywiście, chciałby wziąć udział w rozwijaniu tego kodu, obejrzyjcie go. Znajduje się w module ntfs-driver-tng w repozytorium linux-ntfs CVS na Sourceforge. URL do szczegółowych informacji o dostępie do cvs:

http://sourceforge.net/cvs/?group_id=13956

Miejcie na uwadze, że moduł ten wymaga pewnych drobnych zmian w rdzeniu jądra; stosowna łata jest dostępna w katalogu ntfs-driver-tng/patches. Obecnie jest to łata na jądro 2.4.15-pre4, ale równie dobrze może być zaaplikowana do późniejszych jąder -pre.

Po nałożeniu łaty i zainstalowaniu źródeł nowego modułu NTFS, NTFS TNG jest zupełnie oddzielone od drzewa jądra (cały kod, łącznie z nagłówkami, jest w fs/ntfs i nigdzie więcej; nie ma też zależności z include/linux/fs.h).

Jedno ostrzeżenie: NTFS TNG do kompilacji wymaga gcc-2.96 lub nowszego. Nie skompiluje się przy użyciu wcześniejszych wersji gcc! Zostaniecie zasypani milionem błędów, jeżeli będziecie próbować któregoś z wcześniejszych gcc...