objaśnienie specyfikacji chown (1) POSIX

Specyfikacja POSIX chownnarzędzia wspomina w sekcji uzasadnienia o chown user:groupskładni (dawniej chown user.group) (moje wyróżnienie):

Metoda 4.3 BSD określająca zarówno właściciela, jak i grupę została uwzględniona w tym tomie POSIX.1-2008, ponieważ:

• Są przypadki, w których pożądany warunek końcowy nie mógł zostać osiągnięty za pomocą narzędzi chgrp i chown (które tylko zmieniły identyfikator użytkownika). (Jeśli bieżący właściciel nie jest członkiem żądanej grupy, a żądany właściciel nie jest członkiem bieżącej grupy, funkcja chown () może się nie powieść, chyba że zarówno właściciel, jak i grupa zostaną zmienione w tym samym czasie).

Myślałem, że user:groupskładnia jest wygodna. Teraz powyższe implikuje, że są rzeczy, które możesz zrobić, z chown user:groupktórymi nie możeszchgrp group; chown user

Teraz ten tekst nie ma dla mnie sensu. W 4.3BSD tylko root może zmienić właściciela pliku, więc w żadnym wypadku nie ma ograniczeń co do tego, co może zrobić.

SysV i kilka innych systemów zezwala (lub pozwala) właścicielowi pliku na zmianę użytkownika i grupy plików na cokolwiek, ale nawet w tych systemach ten tekst powyżej nie ma dla mnie sensu. OK, jeśli ktoś to zrobi chown someone-else the-file, nie da się tego zrobić chgrp something-else the-filepóźniej, ponieważ nie jest już właścicielem pliku, ale nic nie stoi na przeszkodzie, aby zrobił to chgrppierwszy (pozostając właścicielem pliku) i chownpóźniej, i to nie jest to powyższy tekst dokładnie mówi.

Nie rozumiem, co ten i pożądany właściciel nie jest członkiem bieżącej grupy, ma związek z tym problemem.

Więc jakie są warunki, dla których funkcja chown () może zawieść, chyba że zarówno właściciel, jak i grupa zostaną zmienione w tym samym czasie i w jakim systemie?

Microsoft Interix podsystem Unix (obecnie na emeryturze) do jej jądra NT traktowane trochę inaczej z uprawnieniami użytkowników i grup niż niektórzy inni:

Informacje o użytkownikach i grupach są przechowywane w bazie danych Security Access . Zarówno użytkownicy, jak i grupy są przechowywane w tej samej bazie danych, ale nazwy grup i użytkowników muszą być unikalne; żadna grupa nie może mieć nazwy użytkownika i odwrotnie. (Ta baza danych zastępuje pliki /etc/passwdi /etc/groupsw systemie UNIX.) Użytkownicy i grupy są tworzone przy użyciu odpowiedniej metodologii Windows (Menedżer użytkowników, Użytkownicy i komputery usługi Active Directory lub Użytkownicy i grupy lokalne) lub za pomocą net userpolecenia Win32 . (Przykładowe skrypty powłoki do tworzenia i usuwania użytkowników znajdują się w katalogu /usr/examples/admin.) Użytkownicy mogą należeć do wielu grup.

Oto kilka bardziej szczegółowych fragmentów instrukcji:

W systemie Windows użytkownik lub grupa może być właścicielem obiektu. Różni się to od systemu UNIX, w którym tylko użytkownik jest właścicielem obiektu.

Windows wewnętrznie identyfikuje wszystkich użytkowników i grupy za pomocą identyfikatora bezpieczeństwa (SID) . Algorytm mieszający generuje unikalne wartości SID; żaden z dwóch użytkowników lub grup nie będzie miał tego samego identyfikatora SID.

Użytkownicy i grupy, które mają uprawnienia dostępu do obiektu, są identyfikowane przez SID. Wszystkie obiekty, które można zabezpieczyć przez system Windows, mają dowolną listę kontroli dostępu (DACL), która składa się z oddzielnych pozycji zwanych pozycjami kontroli dostępu (ACE). Lista ACE zawiera dwie ważne informacje: identyfikator SID użytkownika lub grupy oraz opis, jaki dostęp do obiektu ma dany użytkownik lub grupa.

CHGRP

... Zmień identyfikator grupy dla pliku ... użytkownik wywołujący chgrp (1) musi należeć do określonej grupy i być właścicielem pliku lub mieć odpowiednie uprawnienia.

CHOWN

... Operandy właściciela i grupy są opcjonalne; należy jednak podać jedno. Jeśli operand grupy jest określony, musi być poprzedzony dwukropkiem (:).

Właściciel może być określony przez numeryczny identyfikator użytkownika lub nazwę użytkownika. Jeśli nazwa użytkownika jest również numerycznym identyfikatorem użytkownika, operand jest używany jako nazwa użytkownika. Grupa może być numerycznym identyfikatorem grupy lub nazwą grupy. Jeśli nazwa grupy jest także numerycznym identyfikatorem grupy, operand jest używany jako nazwa grupy.

Ze względów bezpieczeństwa własność pliku można zmienić tylko przez proces z odpowiednimi uprawnieniami.

Jak czytam, oznacza to, że jeśli twoje konto użytkownika należy do grupy Windows z wystarczającymi uprawnieniami do modyfikowania uprawnień do pliku, który jest własnością tej grupy, możliwe jest skuteczne działanie chgrptego pliku poza kontrolą konta użytkownika. Sprowadza się to do mniejszej kontroli niż możesz przy chownwyraźnych user:groupparametrach. W tym kontekście bez możliwości zadeklarowania user: i :group nigdy nie można osiągnąć takich samych wyników, jak w innym przypadku.

Oto link do szczegółowego spojrzenia na interakcję Interixa z listami ACL systemu Windows, z naciskiem na to, jak taka wiedza może mieć zastosowanie do systemów plików Samby w innych wariantach Uniksa.

Oto link do przestarzałego dokumentu Solaris opisującego przestrajanie, rstchownktóre ...

Wskazuje, czy semantyka POSIX dla chown(2)wywołania systemowego obowiązuje ...

Najwyraźniej jeśli parametr jest ustawiony na wartość 0...

... wyłączenie semantyki POSIX otwiera potencjał dla różnych luk bezpieczeństwa. Otwiera to również możliwość zmiany właściciela pliku na innego użytkownika i niemożności odzyskania pliku bez interwencji użytkownika lub administratora systemu.

Taka opcja nie unieważnia zgodności POSIX z Solaris . Tylko to, że jest to opcja, kwalifikuje ją jako zgodną :

Chociaż wszystkie implementacje zgodne z POSIX.1-2008 obsługują wszystkie funkcje opisane poniżej, mogą istnieć procedury konfiguracyjne zależne od systemu lub systemu plików, które mogą usuwać lub modyfikować dowolne lub wszystkie z tych funkcji. Takich konfiguracji nie należy wykonywać, jeśli wymagana jest ścisła zgodność.

Następujące stałe symboliczne należy zdefiniować za pomocą wartości innej niż -1. Jeśli stała jest zdefiniowana z wartością zero, aplikacje powinny używać sysconf(), pathconf()lub fpathconf()funkcje lub getconfnarzędzia, aby określić, które cechy są obecne w systemie w tym czasie lub dla danej ścieżki w pytaniu.

_POSIX_CHOWN_RESTRICTED

Użycie chown()ogranicza się do procesu z odpowiednimi uprawnieniami oraz do zmiany identyfikatora grupy pliku tylko na efektywny identyfikator grupy procesu lub na jeden z jego dodatkowych identyfikatorów grupy.

Funkcja chown()systemowa - która jest udokumentowanym wywołaniem systemowym wykonanym zarówno przez narzędzia, jak chowni chgrpnarzędzia powłoki - jest uznawana za nieudaną z wielu powodów. Pomiędzy nimi:

EACCES Brak uprawnień do wyszukiwania w komponencie prefiksu ścieżki.

ELOOP Pętla istnieje w dowiązaniach symbolicznych napotkanych podczas rozwiązywania argumentu ścieżki.

EPERM Efektywny identyfikator użytkownika nie jest zgodny z właścicielem pliku lub proces wywołujący nie ma odpowiednich uprawnień, a _POSIX_CHOWN_RESTRICTED wskazuje, że takie uprawnienia są wymagane.

Zachowanie polegające na przyznawaniu uprawnień do modyfikacji uprawnień użytkownikom innym niż root nigdy nie było jednak unikalne w systemie Solaris. W tym wpisie na forum jest bardzo doskonałe - choć nieco przestarzałe - pokrycie uprawnień do plików systemu Unix :

Pierwotnie Unix pozwalał właścicielowi pliku na rozdawanie plików. Właściciel pliku może zmienić właściciela na kogoś innego. Użytkownik inny niż root nie mógł cofnąć tej operacji ... BSD [później] usunięto chownz użytkowników innych niż root ... [częściowo dlatego, że] ... zaimplementowano przydziały dysku, które mogłyby ograniczyć ilość miejsca na dysku użytkownik może mieć w systemie plików ... Niegrzeczni użytkownicy mogą rozdawać duże pliki, aby wymknąć się limitom.

Dzisiaj nie jest łatwo stwierdzić, czy plik inny niż root może chownplik. Wiele wersji Uniksa pozwala na oba zachowania ...

Kolejny dobry - i nowszy - post na liście mailowej cytuje to i kontynuuje:

Domyślnie w większości systemów operacyjnych chownogranicza się tylko do rootowania. I istnieje konsensus, że tak powinno pozostać ze względów bezpieczeństwa. Jeśli użytkownik inny niż root nie zmieni właściciela pliku, a dowolny bit wykonania jest włączony, bity SUIDi SGIDmuszą zostać wyczyszczone. To może się zdarzyć lub nie root.

Myślę, że ostatni akapit mówi to ładnie.

Ten artykuł zawiera także odniesienia CAP_CHOWNdo kontrolowania tego narzędzia w systemie Linux (które powinno tylko wpływać na POSIX_CHOWN_RESTRICTEDzachowanie) . Istnieje również CAP_FOWNERmożliwość, która jest nieco inna w zachowaniu.

I jak zauważyłeś w 2003 roku :

Pamiętaj, że przynajmniej w HPUX możesz zmienić właściciela swoich plików ( rootna przykład), nawet jeśli nie jesteś uprzywilejowanym użytkownikiem ...

... które zależały od setprivgroupparametru konfiguracyjnego .

W każdym przypadku, w którym użytkownik inny niż root może manipulować uprawnieniami do plików, można sobie wyobrazić, jak wspomniano w uzasadnieniu cytowanym w pytaniu, że użytkownik może chownmieć plik, który jest właścicielem tego użytkownika, tak że jest on własnością innego użytkownika. Jeśli własność grupy pliku i grupy chownużytkownika ing nie zostaną wyrównane, użytkownik nie będzie już mógł modyfikować tego pliku.

W tym scenariuszu chown następnie chgrp zawiedzie jako użytkownik nie będzie już mieć uprawnień do zmiany uprawnień w tym pliku, podczas gdy chown user:group- tak długo, jak grupa jest jednym z użytkownikiem własnego - uda.

Prawdopodobnie istnieje wiele innych niszowych sytuacji, które mogą wynikać podobnie, na przykład bity lepkie i / lub bity setgid , listy systemów plików i / lub listy kontroli dostępu specyficzne dla implementacji. Ten wątek jest na przykład interesujący. Niezliczone permutacje są daleko poza moim słabym zasięgiem - dlatego ta odpowiedź jest opublikowana w Wikipedii. Jeśli to czytasz, uważasz, że warto to poprawić i wierzysz, że wiesz jak - zrób to .

Istnieje również obszerna dokumentacja na temat różnych możliwych skutków uprawnień do plików, przechodzenia przez drzewa i dowiązań symbolicznych, które mogą powodować podobną awarię w odniesieniu do aplikacji -Recursive chown:

Z nagłówków sekcji POSIX XRAT Trzecia i czwarta domena :

Zasadniczo użytkownicy określający opcję przejścia hierarchii plików chcą działać na pojedynczej, fizycznej hierarchii, dlatego też dowiązania symboliczne, które mogą odnosić się do plików poza hierarchią, są ignorowane. Na przykład plik właściciela właściciela jest inną operacją niż to samo polecenie z podaną opcją -R. W tym przykładzie chown owner fileopisano zachowanie polecenia , a zachowanie chown -Rpliku właściciela polecenia opisano w trzeciej i czwartej domenie.

... Wystąpił problem bezpieczeństwa związany z domyślnym przejściem logicznym. Historycznie chown -Rplik użytkownika polecenia był bezpieczny dla superużytkownika, ponieważ bity setuid i setgid zostały utracone po zmianie własności pliku. Gdyby przejście było logiczne, zmiana własności nie byłaby już bezpieczna, ponieważ użytkownik mógł wstawić symboliczne łącze wskazujące dowolny plik w drzewie. Ponownie wymagałoby to dodania opcji do poleceń przechodzących hierarchię, aby nie pośrednio poprzez dowiązania symboliczne, a skrypty historyczne wykonujące rekurencyjne spacery natychmiast stałyby się problemami bezpieczeństwa. Chociaż jest to głównie problem dla administratorów systemu, lepiej nie mieć różnych ustawień domyślnych dla różnych klas użytkowników.

...

W 4.3 BSD chgrppodczas przechodzenia drzewa zmieniono grupę dowiązania symbolicznego, a nie cel. Dowiązania symboliczne w 4.4 BSD nie miały właściciela, grupy, trybu ani innych standardowych atrybutów plików systemowych UNIX.

A na chgrpwłaściwej stronie POSIX znajduje się ta, która wskazuje na możliwe niekompletne -Rdziałanie ekursywne, a przynajmniej na to, co kiedyś :

Wersje System V i BSD używają różnych kodów statusu wyjścia. Niektóre implementacje wykorzystywały status wyjścia jako liczbę błędów, które wystąpiły; ta praktyka jest niewykonalna, ponieważ może przepełnić zakres prawidłowych wartości statusu wyjścia. Standardowi programiści postanowili je maskować, określając tylko 0 i> 0 jako wartości wyjściowe.

Założenie 1: zasady określania, czy się chownpowiedzie, sprawdzają niezależnie docelowego użytkownika i grupy części, tj. Mają one formę user_condition(target_uid, other_environment_parameters) && group_condition(target_gid, other_environment_parameters).

Założenie 2: chown(file, -1, -1)udane.

Założenie 3: zasady określania, czy się chownpowiedzie, nie zależą od grupy, do której plik należy obecnie.

Następstwo: jeśli chown(file, uid, gid)to się powiedzie, to i tak się stanie chown(file, -1, gid) && chown(file, uid, -1).

Nie znam wariantu Uniksa, który naruszyłby którekolwiek z tych założeń, wydają się one całkiem bezpieczne.

To zdanie ma wygląd czegoś, co ktoś w komisji powiedział, gdy byli zmęczeni godzinami debatowania, ile opcji może zmieścić się na czele psrozmowy - lub że sekretarka źle przepisała - i których nikt nie złapał podczas przeglądu. W końcu istnieją inne dobre powody, aby zezwolić na automatyczną zmianę użytkownika i grupy, w tym powód wydajności wymieniony również w uzasadnieniu POSIX, a także atomowość (ah, gdyby tylko było jedno wezwanie do zmiany własności i uprawnień ).

Przypadek, w którym założenie 3 może być błędne, dotyczy systemu, w którym proces może uzyskać możliwość zmiany właścicieli plików, ale tylko wtedy, gdy mają oni uprawnienia do zapisu pliku. Choć nieco realistyczne, nie znam żadnego systemu, w którym tak jest. Następniechgrp do grupy z procesu, który nie działa ani jako root, ani jako użytkownik będący właścicielem pliku, może spowodować, że plik będzie później niedostępny chown.

W przypadku wywołania rekurencyjnego istnieją przypadki skrajne, w których całe przejście, chgrppo którym następuje całe przejście, chownmoże się nie powieść, gdy pojedyncze przejście zakończy się powodzeniem. Nie jest to zbyt przekonujący argument, ponieważ dotyczy katalogów, których właściciel nie ma uprawnień do przechodzenia, a aplikacja, która chciała chronić się przed wszystkimi takimi przypadkami, musiałaby i tak manipulować uprawnieniami. Niemniej jednak technicznie spełnia warunek tego uzasadnienia. Załóżmy, że działający proces ma efektywnego użytkownika alice, skuteczną grupę staffi możliwość arbitralnej zmiany właścicieli plików (nie tylko w celu ich rozdania; kilka wariantów uniksowych ma taką możliwość, chociaż rzadko jest to przyznawane procesom innym niż root).

$ ls -ld dir dir/file
d---rwx---  2 charlie  staff        1024 Apr  1  1970 dir
drw-rw----  2 charlie  staff          42 Apr  1  1970 file
$ chgrp -R students dir
$ chown -R bob dir
chown: dir: permission denied