Dlaczego chmod (1) w grupie wpływa na maskę ACL?

Próbuję zrozumieć to zachowanie w systemie Unix (testowane na Ubuntu 11.10):

$ touch foo
$ setfacl -m u:nobody:rwx foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx
group::rw-
mask::rwx
other::r--

$ chmod g-rw foo
$ getfacl foo
# file: foo
# owner: michael
# group: michael
user::rw-
user:nobody:rwx         #effective:--x
group::rw-          #effective:---
mask::--x
other::r--

Zauważ, że komenda chmod (1) zaktualizowała maskę ACL. Dlaczego to się dzieje?

Strona SunOS ma następujące zdanie:

Jeśli użyjesz komendy chmod (1) do zmiany uprawnień właściciela grupy plików w pliku z wpisami ACL, zarówno uprawnienia właściciela grupy plików, jak i maska ​​ACL zostaną zmienione na nowe uprawnienia. Należy pamiętać, że nowe uprawnienia do maski ACL mogą zmienić efektywne uprawnienia dla dodatkowych użytkowników i grup, które mają wpisy ACL w pliku.

Pytam, ponieważ byłoby dla mnie wygodne, gdyby chmod (1) nie miał takiego zachowania. Mam nadzieję, że rozumiejąc, dlaczego robi to, co robi, mogę lepiej zaprojektować sposób konfigurowania uprawnień systemu plików.

To byłoby nie być wygodne dla Ciebie, jeśli chmod()nie mają tego problemu.

Byłoby to bardzo niewygodne, ponieważ załamałyby się rzeczy, które ludzie tradycyjnie oczekują od Unixów. To zachowanie dobrze ci służy, czy wiesz o tym.

Szkoda, że ​​IEEE 1003.1e nigdy nie stał się standardem i został wycofany w 1998 roku. W praktyce, czternaście lat później, jest to standard, który wdraża szeroka gama systemów operacyjnych - od Linuksa poprzez FreeBSD po Solaris .

Projekt roboczy nr 17 IEEE 1003.1e stanowi ciekawą lekturę i polecam go. W załączniku B § 23.3 grupa robocza przedstawia szczegółowe ośmiostronicowe uzasadnienie nieco złożonego sposobu działania list ACL POSIX w odniesieniu do starych S_IRWXGflag uprawnień grupowych. (Warto zauważyć, że ludzie TRUSIX dostarczyli tę samą analizę dziesięć lat wcześniej.) Nie zamierzam tu wszystkiego kopiować. Szczegółowe informacje znajdują się w uzasadnieniu projektu standardu. Oto bardzo krótka zasada :

• Instrukcja SunOS jest nieprawidłowa. To powinien przeczytać

  Jeśli użyjesz chmod(1)komendy, aby zmienić uprawnienia właściciela grupy plików na pliku z wpisami ACL, albo uprawnienia właściciela grupy plików lub maskę ACL są zmieniane na nowe uprawnienia.

  Takie zachowanie możesz zaobserwować , niezależnie od tego, co mówi bieżąca strona podręcznika w pytaniu. Jest to również zachowanie określone w projekcie standardu POSIX. Jeśli istnieje pozycja kontroli dostępu ( CLASS_OBJterminologia Sun i TRUSIX dla ACL_MASK), bity grupy chmod()ustawiają ją, w przeciwnym razie ustawiają GROUP_OBJpozycję kontroli dostępu.

• Gdyby tak nie było, aplikacje, które zrobiły różne standardowe rzeczy za pomocą `chmod ()`, oczekując, że będzie działać tak, jak `chmod ()` tradycyjnie działało na starych uniksach innych niż ACL, zostawiłoby luki w zabezpieczeniach lub zobaczyłoby co uważają, że stanowią luki w zabezpieczeniach:

  • Tradycyjne aplikacje uniksowe oczekują możliwości odmowy dostępu do pliku, nazwanego potoku, urządzenia lub katalogu za pomocą chmod(…,000). W przypadku list ACL powoduje to wyłączenie wszystkich uprawnień użytkowników i grup, jeśli stare S_IRWXGmapy to CLASS_OBJ. Bez tego ustawienie starych uprawnień do plików na 000nie wpływałoby na żadne wpisy USERani GROUPwpisy, a inni użytkownicy, co zaskakujące, nadal mieliby dostęp do obiektu.

    Tymczasowa zmiana bitów uprawnień do pliku na brak dostępu, chmod 000a następnie ich ponowna zmiana była starym mechanizmem blokowania plików, używanym zanim Unixy zyskały doradcze mechanizmy blokowania, które - jak widać - ludzie nadal używają .

  • Tradycyjne skrypty uniksowe oczekują, że będą mogły zostać uruchomione, chmod go-rwxa tylko właściciel obiektu będzie mógł uzyskać do niego dostęp. Ponownie - jak widzicie - wciąż jest to otrzymana mądrość dwanaście lat później. I znowu, to nie działa, chyba że stare S_IRWXGmapy to, CLASS_OBJjeśli istnieją, ponieważ w przeciwnym razie to chmodpolecenie nie wyłączyłoby żadnych wpisów kontroli dostępu USERani nie GROUPdoprowadziło do tego, że użytkownicy inni niż właściciel i grupy niebędące właścicielami zachowują dostęp do czegoś, co jest oczekuje się, że będzie dostępny tylko dla właściciela.

  • System, w którym bity uprawnień byłyby oddzielne i andedytowane z listami ACL, rwxrwxrwxw większości przypadków wymagałby użycia flag uprawnień do plików , co dezorientowałoby cholernie wiele aplikacji uniksowych, które narzekają, gdy widzą, co uważają za światowe rzeczy.

    System, w którym bity uprawnień byłyby oddzielone od orlist ACL i edytowane z nimi, miałby chmod(…,000)problem wspomniany wcześniej.

Dalsza lektura

• Winfried Trümper (1999-02-28). Podsumowanie o Posix.1e
• Komitet ds. Standardów Aplikacji Przenośnych Towarzystwa Komputerowego IEEE (październik 1997 r.). Projekt standardu dla technologii informatycznych - Interfejs przenośnego systemu operacyjnego (POSIX) - Część 1: Interfejs programu aplikacji systemu (API) - Poprawka nr: Interfejsy ochrony, audytu i kontroli [język C] IEEE 1003.1e. Projekt 17.
• Craig Rubin (1989-08-18). Uzasadnienie wyboru funkcji listy kontroli dostępu dla systemu Unix . NCSC-TG-020-A. Wydawnictwo DIANE. ISBN 9780788105548.

To zachowanie dotyczy tylko pozycji ACL POSIX. Powodem jest to, że jeśli masz folder, a wewnątrz tego folderu istnieje plik, możesz acl jako rwx (na przykład) folder i plik. Jeśli uprawnienia grupy do pliku to rw- (które mogą być typowym scenariuszem), maska ​​daje acl efektywne uprawnienia rw - nawet jeśli ACL wyraźnie oznacza rwx.

Z drugiej strony katalog, który prawie zawsze jest + x, ma efektywne uprawnienia maski ACL, pozwalające również na + x.

Podsumowując, ta maska ​​służy zasadniczo do rozróżnienia uprawnień między plikami i folderami dla zestawu ACL POSIX, aby plik nie był wykonywalny, gdy normalnie nie powinien być.