Pierwszeństwo użytkownika i właściciela grupy w uprawnieniach do plików

Właśnie natrafiłem na coś nieoczekiwanego (dla mnie) dotyczącego uprawnień do plików w systemie Linux (Arch Linux). Zasadniczo mam:

• userX w groupX
• fileX userX:groupX ---rwx----

Co mnie zastanawia: nie mogę wykonać żadnej akcji ( rwx) fileX. Czy to jest poprawne? Czy ktoś może potwierdzić, że rzeczywiście jest to oczekiwane zachowanie?

Jedyne czynności, które mogę wykonać, mvi rmponieważ mam uprawnienia do zapisu w katalogu nadrzędnym.

Rzecz w tym, że zawsze myślałem, że te uprawnienia się załamują, zaczynając od najbardziej ogólnego (inne -> grupa -> użytkownik). Innymi słowy, jeśli o=rwxkogo to obchodzi, jakie są przekonania dla grupy i użytkownika? Najwyraźniej tak nie jest, ale nie ma to dla mnie większego sensu; wydaje się to sprzeczne z intuicją. Jedyne, co wydaje się przydatne w tym podejściu, to łatwe wykluczenie bardzo konkretnej osoby / grupy, co nie wydaje się być mądrym sposobem na to (imho). Poza tym właściciel (i grupa?) I tak powinien móc, chmodprawda? Masz jakieś przemyślenia na ten temat?

Rzecz w tym, że zawsze myślałem, że te uprawnienia się załamują, zaczynając od najbardziej ogólnego (inne -> grupa -> użytkownik).

Gdyby tak było, wówczas dla wszystkich obowiązywałyby „inne” uprawnienia.

Innymi słowy, jeśli o = rwx, kogo to obchodzi, jakie są oczekiwania dla grupy i użytkownika?

To różni się od twojego poprzedniego zdania. Tutaj sugerujesz, że uprawnienia są lub są połączone razem, np. Że użytkownik X ma uprawnienia do odczytu, jeśli użytkownik X jest właścicielem pliku i plik jest czytelny dla użytkownika, lub jeśli grupa, do której należy użytkownik X, jest właścicielem pliku, a plik jest grupą -czytelny lub jeśli plik można odczytać w inny sposób. Ale nie tak to działa. W rzeczywistości o=rwxoznacza to, że rwxuprawnienia dotyczą innych, ale nie mówi nic o podmiotach, które nie są innymi.

Po pierwsze, nie ma bezpośredniego znaczenia, do której grupy należy użytkownik. Jądro nie ma pojęcia użytkowników należących do grup. Jądro utrzymuje dla każdego procesu identyfikator użytkownika ( efektywny UID ) i listę identyfikatorów grup (efektywny GID i dodatkowe GID). Grupy są określane w czasie logowania przez proces logowania - to proces logowania odczytuje bazę danych grupy (np /etc/group.). Identyfikatory użytkowników i grup są dziedziczone przez procesy potomne¹.

Gdy proces próbuje otworzyć plik z tradycyjnymi uprawnieniami w systemie Unix:

• Jeśli użytkownik będący właścicielem pliku jest efektywnym identyfikatorem UID procesu, używane są bity uprawnień użytkownika.
• W przeciwnym razie, jeśli grupa będąca właścicielem pliku jest efektywnym GID procesu lub jednym z dodatkowych identyfikatorów grupy procesu, wówczas używane są bity uprawnień grupy.
• W przeciwnym razie używane są inne bity uprawnień.

Zawsze używany jest tylko jeden zestaw bitów rwx. Użytkownik ma pierwszeństwo przed grupą, która ma pierwszeństwo przed innymi. Gdy istnieją listy kontroli dostępu , algorytm opisany powyżej jest uogólniony:

• Jeśli w pliku znajduje się lista ACL dla efektywnego identyfikatora UID procesu, służy ona do ustalenia, czy udzielono dostępu.
• W przeciwnym razie, jeśli w pliku znajduje się lista ACL dla efektywnego identyfikatora GID procesu lub jednego z dodatkowych identyfikatorów grupy procesu, używane są bity uprawnień grupy.
• W przeciwnym razie używane są inne bity uprawnień.

Zobacz także Pierwszeństwo ACLS, gdy użytkownik należy do wielu grup, aby uzyskać więcej informacji na temat korzystania z wpisów ACL, w tym efektu maski.

W ten sposób -rw----r-- alice internswskazuje plik, który Alice może odczytać i zapisać, i który może odczytać wszyscy inni użytkownicy oprócz stażystów. Plik z uprawnieniami i prawem własności ----rwx--- alice internsjest dostępny tylko dla stażystów, z wyjątkiem Alicji (bez względu na to, czy jest stażystą, czy nie). Ponieważ Alicja może dzwonić w chmodcelu zmiany uprawnień, nie zapewnia to żadnych zabezpieczeń; to jest skrzynia krawędzi. W systemach z listami ACL uogólniony mechanizm pozwala na usunięcie uprawnień określonych użytkowników lub określonych grup, co czasem jest przydatne.

Użycie jednego zestawu bitów zamiast uporządkowania wszystkich bitów dla każdej akcji (odczyt, zapis, wykonanie) ma kilka zalet:

• Przydaje się to, umożliwiając usuwanie uprawnień z zestawu użytkowników lub grup w systemach z listami ACL. W systemach bez list ACL uprawnienia można usunąć z jednej grupy.
• Łatwiej jest go zaimplementować: sprawdź jeden zestaw bitów zamiast łączyć kilka zestawów bitów razem.
• Łatwiej jest analizować uprawnienia do pliku, ponieważ wymaga mniej operacji.

¹ _{Mogą się zmieniać, gdy wykonywany jest proces setuid lub setgid. Nie ma to związku z danym problemem.}

Bardziej szczegółowe uprawnienia mają pierwszeństwo przed mniej szczegółowymi.

userX w grupieX

fileX userX: groupX --- rwx ----

Ponieważ jesteś właścicielem pliku, otrzymasz tylko uprawnienia właściciela. Właściciel nie ma uprawnień. Dlatego nic nie możesz zrobić. Gdybyś nie był właścicielem pliku i członkiem grupy, obowiązywałyby uprawnienia grupy.

Przeczytaj tę sekcję strony wiki

https://en.wikipedia.org/wiki/File_system_permissions#Classes

-rwxrw---- oznacza, że ​​właściciel ma uprawnienia do odczytu, zapisu i wykonywania, grupa ma uprawnienia do odczytu i zapisu, a inni nie mają uprawnień.

Podane uprawnienia dają grupie „groupX” uprawnienia do odczytu, zapisu i wykonania pliku. Jeśli jesteś członkiem grupy „groupX”, ale nie jesteś właścicielem pliku, te uprawnienia będą obowiązywać.

W tym przypadku zakładam, że rzeczywiście jesteś właścicielem pliku. Zastosowanie będą miały tylko uprawnienia ustawione dla właściciela. Oczywiście właściciel może zastąpić lub zmienić uprawnienia do pliku. Grupa nie może tego jednak zrobić. Na przykład vim poprosi cię o potwierdzenie, czy piszesz do pliku, do którego nie masz uprawnień do zapisu, ale jesteś właścicielem.

Zwykle czytam uprawnienia od lewej do prawej. Czy jestem właścicielem? Jeśli tak, obowiązują uprawnienia właściciela. Jeśli nie; czy jestem członkiem grupy? Jeśli tak, obowiązują uprawnienia grupowe. Jeśli nie, to dotyczą mnie uprawnienia do „Inne”.

W niektórych przypadkach warto być właścicielem pliku, ale nie mieć uprawnień do zapisu. Chroni przed przypadkowym usunięciem lub modyfikacją pliku. Osobiście ustawiłem uprawnienia 400 na wszystkie moje pliki szablonów, aby upewnić się, że nie zmodyfikuję ich przypadkowo. To samo dotyczy uprawnień do wykonywania.

Byłem w stanie dodać użytkownika do grupy, nadać grupie uprawnienia do katalogu (070), a następnie PO PONOWNYM PONOWNYM uruchomieniu dostępu do folderu.

Utwórz grupę: sudo groupadd nazwa grupy

Dodaj użytkownika do grupy: sudo gpasswd -a nazwa użytkownika nazwa grupy

Upewnij się, że cały katalog ma poprawne prawo własności do grupy (aby występować, musi być bieżącym członkiem nazwy grupy): sudo chgrp -R nazwa_grupy ścieżka do katalogu /

Podaj tylko grupę rwx dla folderu (może to być tylko rw, dostosuj w razie potrzeby): sudo chmod -R 070 ścieżka_katalogu

Po wykonaniu powyższych czynności wyloguj się i zaloguj ponownie. Jeśli to nie zadziała, uruchom ponownie komputer. To działało dla mnie.