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…”.
linux
permissions
Yuval
źródło
źródło
devsgrupy pozwala na to.fooczłonkiem grupfooidevsprzypisać udostępnione pliki dodevgrupy, a prywatne pliki dofoogrupyOdpowiedzi:
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 trybem
rwsr-x---będącym własnościąroot:adminpozwala tylko użytkownikom wadmingrupie 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.
źródło
Uprawnienia użytkownika / grupy / inne do pliku są częścią oryginalnego projektu uniksowego.
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 / zapisuroot.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 tutaj
group/otheruprawnienia, 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łejuser:userwłasności, ale w innych przypadkach sensowne jest nadanie muuser:groupwłasności.Przyznaję, że łatwo to zrobić, ale równie łatwo można to zrobić z istnieniem
othergrupy ...Podkreśliłem tę część twojego oświadczenia, która wydaje się powtarzać moją uwagę na temat logicznej konieczności
otherkategorii 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.
źródło
The UNIX Time-Sharing System, napisane przez Dennisa M. Ritchiego i Kena Thomsona w 1974 r., Pierwotnie było 7 bitów na pozwolenia:Also given for new files is a set of seven protection bits. Six of these specify independently read, write, and execute permission for the owner of the file and for all other users.(Siódmy bit byłsetuidbitem).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.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).
600lub400: Dostęp tylko dla użytkownika (i tak, udzielam użytkownikowi dostępu tylko do odczytu).640lub660: Dostęp użytkownika i grupy.644,666Lub664: 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:
700lub500: Dostęp tylko dla użytkownika750lub710: Dostęp tylko do grupy755,777,775, Lub751: 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.
źródło
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.
źródło