Czy istnieje powód, dla którego istnieją uprawnienia „właściciela”? Czy uprawnienia grupowe nie są wystarczające?

Myślę, że raczej rozumiem, jak działają uprawnienia do plików w systemie Linux. Jednak tak naprawdę nie rozumiem, dlaczego są one podzielone na trzy poziomy, a nie na dwa.

Chciałbym odpowiedzieć na następujące problemy:

• Czy to celowy projekt czy łatka? To znaczy - czy uprawnienia właściciela / grupy zostały zaprojektowane i utworzone wraz z uzasadnieniem, czy też przychodzą jeden po drugim, aby odpowiedzieć na potrzebę?
• Czy istnieje scenariusz, w którym użytkownik / grupa / inny schemat jest przydatny, ale schemat grupy / innego nie wystarczy?

Odpowiedzi na pierwsze powinny zawierać zarówno podręczniki, jak i oficjalne fora dyskusyjne.

Przypadki zastosowania, które rozważałem, to:

• pliki prywatne - bardzo łatwo dostępne poprzez utworzenie grupy dla użytkownika, co często jest wykonywane tak jak w wielu systemach.
• zezwalając tylko właścicielowi (np. usłudze systemowej) na zapisywanie do pliku, zezwalając tylko pewnej grupie na odczyt i odmawiając dostępu do wszystkich innych - problem z tym przykładem polega na tym, że gdy grupa musi mieć dostęp do zapisu, użytkownik / group / other zawiedzie z tym. Odpowiedzią dla obu jest użycie list ACL i nie usprawiedliwia IMHO istnienia uprawnień właściciela.

NB Udoskonaliłem to pytanie po zamknięciu pytania w superuser.com .

Edycja poprawiona „ale schemat grupy / właściciela nie wystarczy” do „… grupy / innej…”.

Historia

Początkowo Unix miał uprawnienia tylko dla użytkownika będącego właścicielem, a dla innych użytkowników: nie było grup. Zobacz w szczególności dokumentację Uniksa w wersji 1 chmod(1). Tak więc zgodność wsteczna, jeśli nic więcej, wymaga uprawnień użytkownika będącego właścicielem.

Grupy przyszły później. Listy ACL pozwalające na włączenie więcej niż jednej grupy w uprawnienia do pliku pojawiły się znacznie później.

Ekspresyjna moc

Posiadanie trzech uprawnień do pliku pozwala uzyskać bardziej szczegółowe uprawnienia niż posiadanie tylko dwóch, przy bardzo niskim koszcie (dużo niższym niż listy ACL). Na przykład plik może mieć tryb rw-r-----: zapis tylko dla użytkownika będącego właścicielem, możliwy do odczytania przez grupę.

Innym przypadkiem użycia są pliki wykonywalne setuid, które są wykonywane tylko przez jedną grupę. Na przykład program z trybemrwsr-x--- będącym własnością root:adminpozwala tylko użytkownikom w admingrupie na uruchomienie tego programu jako root.

„Istnieją uprawnienia, których ten schemat nie może wyrazić”, to straszny argument przeciwko niemu. Obowiązującym kryterium jest to, czy istnieje wystarczająca liczba wyraźnych przypadków uzasadniających koszt? W tym przypadku koszt jest minimalny, szczególnie biorąc pod uwagę inne powody, dla których użytkownik / grupa / inny tryptyk.

Prostota

Posiadanie jednej grupy na użytkownika ma niewielki, ale nie bez znaczenia narzut zarządzania. Dobrze, że niezwykle częsty przypadek pliku prywatnego nie zależy od tego. Aplikacja, która tworzy prywatny plik (np. Program dostarczający pocztę e-mail) wie, że wystarczy nadać temu plikowi tryb 600. Nie musi przechodzić przez bazę danych grupy w poszukiwaniu grupy zawierającej tylko użytkownika - i co zrobić, jeśli nie ma takiej grupy lub więcej niż jednej?

Idąc z innej strony, załóżmy, że widzisz plik i chcesz sprawdzić jego uprawnienia (tj. Sprawdź, czy są takie, jakie powinny być). Jest to o wiele łatwiejsze, gdy można przejść „dostępne tylko dla użytkownika, w porządku, dalej” niż wtedy, gdy trzeba prześledzić definicje grup. (Taka złożoność jest zmorą systemów, które intensywnie wykorzystują zaawansowane funkcje, takie jak listy ACL lub możliwości.)

Ortogonalność

Każdy proces wykonuje dostęp do systemu plików jako określony użytkownik i określona grupa (przy bardziej skomplikowanych regułach dotyczących nowoczesnych uników, które obsługują grupy dodatkowe). Użytkownik jest używany do wielu rzeczy, w tym do testowania rootowania (UID 0) i pozwolenia na dostarczanie sygnału (na podstawie użytkownika). Istnieje naturalna symetria między rozróżnianiem użytkowników i grup w uprawnieniach procesu a rozróżnianiem użytkowników i grup w uprawnieniach systemu plików.

Czy to celowy projekt czy łatka? To znaczy - czy uprawnienia właściciela / grupy zostały zaprojektowane i utworzone wraz z uzasadnieniem, czy też przychodzą jeden po drugim, aby odpowiedzieć na potrzebę?

Uprawnienia użytkownika / grupy / inne do pliku są częścią oryginalnego projektu uniksowego.

Czy istnieje scenariusz, w którym użytkownik / grupa / inny schemat jest przydatny, ale schemat grupy / właściciela nie wystarczy?

Tak, praktycznie każdy scenariusz, jaki mogłem sobie wyobrazić, w którym miejscu ważne jest bezpieczeństwo i kontrola dostępu.

Przykład: Możesz chcieć nadać niektórym plikom binarnym / skryptom dostęp do systemu tylko do wykonywania i ograniczyć dostęp do otherodczytu / zapisu root.

Nie jestem pewien, co masz na myśli dla modelu uprawnień systemu plików, który ma tylko uprawnienia właściciela / grupy. Nie wiem, jak można mieć bezpieczny system operacyjny bez istnienia otherkategorii.

EDYCJA: Załóżmy, że miałeś na myśli tutajgroup/other uprawnienia, które są potrzebne, a następnie sugeruję opracowanie sposobu zarządzania kluczami kryptograficznymi lub sposobu, w jaki tylko odpowiedni użytkownicy mogą uzyskać dostęp do swojego bufora poczty. Są przypadki, w których klucz prywatny może wymagać ścisłej user:userwłasności, ale w innych przypadkach sensowne jest nadanie mu user:groupwłasności.

pliki prywatne - bardzo łatwo dostępne poprzez utworzenie grupy dla użytkownika, co często jest wykonywane tak jak w wielu systemach.

Przyznaję, że łatwo to zrobić, ale równie łatwo można to zrobić z istnieniem other grupy ...

zezwalając tylko właścicielowi (np. usłudze systemowej) na zapis do pliku, zezwalając tylko pewnej grupie na odczyt i odmawiając wszystkim innym dostępom - problem w tym przykładzie polega na tym, że gdy grupa wymaga posiadania dostępu do zapisu, użytkownik / group / other zawiedzie z tym. Odpowiedzią dla obu jest użycie list ACL i nie usprawiedliwia IMHO istnienia uprawnień właściciela.

Podkreśliłem tę część twojego oświadczenia, która wydaje się powtarzać moją uwagę na temat logicznej konieczności other kategorii uprawnień w systemie plików Unix.

Taki projekt systemu plików, jak się wydaje, rozważasz (z tego, co mogę powiedzieć) byłby niepewny lub niewygodny. Unix został zaprojektowany przez niektórych bardzo inteligentnych ludzi i myślę, że ich model zapewnia najlepszą możliwą równowagę bezpieczeństwa i elastyczności.

Czy to celowy projekt czy łatka? To znaczy - czy uprawnienia właściciela / grupy zostały zaprojektowane i utworzone wraz z uzasadnieniem, czy też przychodzą jeden po drugim, aby odpowiedzieć na potrzebę?

Tak, jest to celowy projekt, który jest obecny w UNIX od pierwszych dni. Został zaimplementowany w systemach, w których pamięć była mierzona w KB, a procesory były bardzo wolne jak na dzisiejsze standardy. Ważna była wielkość i szybkość takich wyszukiwań. Listy ACL wymagałyby więcej miejsca i były wolniejsze. Funkcjonalnie everyonegrupa jest reprezentowana przez inne flagi bezpieczeństwa.

Czy istnieje scenariusz, w którym użytkownik / grupa / inny schemat jest przydatny, ale schemat grupy / właściciela nie wystarczy?

Uprawnienia, których zwykle używam do dostępu do plików to: (Używam wartości bitów dla uproszczenia i ponieważ tak zwykle je ustawiam).

• 600lub 400: Dostęp tylko dla użytkownika (i tak, udzielam użytkownikowi dostępu tylko do odczytu).
• 640lub 660: Dostęp użytkownika i grupy.
• 644, 666Lub 664: użytkownika, grupy i inne dostępu. Każdy dwupoziomowy schemat uprawnień może obsługiwać tylko dwa z tych trzech przypadków. Trzeci wymagałby list ACL.

W przypadku katalogów i programów zwykle używam:

• 700lub 500: Dostęp tylko dla użytkownika
• 750lub 710: Dostęp tylko do grupy
• 755, 777, 775, Lub 751: użytkownika, grupy i inne dostępu. Obowiązują te same komentarze, co w przypadku plików.

Powyższe są najczęściej używane, ale nie wyczerpująca lista ustawień uprawnień, których używam. Powyższe uprawnienia w połączeniu z grupą (czasem z lepkim bitem grupy w katalogach) były wystarczające we wszystkich przypadkach, w których mogłem użyć ACL.

Jak wspomniano powyżej, bardzo łatwo jest wymienić uprawnienie na liście katalogów. Jeśli listy ACL nie są używane, mogę kontrolować uprawnienia dostępu tylko z listą katalogów. Kiedy pracuję z systemami opartymi na ACL, bardzo trudno jest mi zweryfikować lub skontrolować uprawnienia.

System uprawnień użytkownika / grupy / innego został zaprojektowany przed wynalezieniem list ACL. Wraca do początków systemu UNIX, więc nie można powiedzieć, że problem powinien zostać rozwiązany za pomocą list ACL. Nawet jeśli koncepcja ACL wydaje się oczywista, wymagałoby to znacznego [na dzień] dodatkowego obciążenia na przechowywanie i zarządzanie zmienną ilością informacji o uprawnieniach dla każdego pliku, a nie na ustaloną kwotę.

Korzystanie z list ACL do wszystkiego oznacza również, że nie masz dobrze zdefiniowanego podzbioru informacji o uprawnieniach, które można wyświetlić „na pierwszy rzut oka”. Dane wyjściowe dla ls -lpokazuje standardowe uprawnienia (użytkownik / grupa / inne), nazwę użytkownika i grupy oraz dodatkową notację (np. +Lub@ znak) na pozycjach, które są powiązane z listą ACL, wszystko w jednym wierszu. Twój system wymagałby zidentyfikowania „dwóch najlepszych” grup na liście ACL, aby zapewnić równoważną funkcjonalność.

Jako dodatkowy punkt, plik nadal musi mieć właściciela w modelu UNIX, ponieważ listy ACL w systemie UNIX nie określają, kto może modyfikować listę ACL.