Specyfikacja POSIX chown
narzędzia wspomina w sekcji uzasadnienia o chown user:group
skł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:group
składnia jest wygodna. Teraz powyższe implikuje, że są rzeczy, które możesz zrobić, z chown user:group
któ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-file
później, ponieważ nie jest już właścicielem pliku, ale nic nie stoi na przeszkodzie, aby zrobił to chgrp
pierwszy (pozostając właścicielem pliku) i chown
póź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?
chown me:my-group file
jeśli plik znajduje się w lokalizacji, w której mam dostęp do odczytu / zapisu (nie jest lepki). Najpierw nie mogłem chgrp jako nie właściciela. Nie mogłem pierwszy zrobić, ponieważ spowodowałoby to utworzenie pliku, którego nie mogłem utworzyć: jestem właścicielem pliku z grupą, do której nie należę.Odpowiedzi:
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:
Oto kilka bardziej szczegółowych fragmentów instrukcji:
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
chgrp
tego pliku poza kontrolą konta użytkownika. Sprowadza się to do mniejszej kontroli niż możesz przychown
wyraźnychuser:group
parametrach. W tym kontekście bez możliwości zadeklarowaniauser:
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,
rstchown
które ...Najwyraźniej jeśli parametr jest ustawiony na wartość
0
...Taka opcja nie unieważnia zgodności POSIX z Solaris . Tylko to, że jest to opcja, kwalifikuje ją jako zgodną :
Funkcja
chown()
systemowa - która jest udokumentowanym wywołaniem systemowym wykonanym zarówno przez narzędzia, jakchown
ichgrp
narzędzia powłoki - jest uznawana za nieudaną z wielu powodów. Pomiędzy nimi: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 :
Kolejny dobry - i nowszy - post na liście mailowej cytuje to i kontynuuje:
I jak zauważyłeś w 2003 roku :
... które zależały od
setprivgroup
parametru 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
chown
mieć 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 grupychown
użytkownika ing nie zostaną wyrównane, użytkownik nie będzie już mógł modyfikować tego pliku.W tym scenariuszu
chown
następniechgrp
zawiedzie jako użytkownik nie będzie już mieć uprawnień do zmiany uprawnień w tym pliku, podczas gdychown 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
-R
ecursivechown
:Z nagłówków sekcji POSIX XRAT Trzecia i czwarta domena :
A na
chgrp
właściwej stronie POSIX znajduje się ta, która wskazuje na możliwe niekompletne-R
działanie ekursywne, a przynajmniej na to, co kiedyś :źródło
chgrp
chown
... może nie zachowywać się tak, jak się spodziewasz ...Założenie 1: zasady określania, czy się
chown
powiedzie, 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ę
chown
powiedzie, 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ę staniechown(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
ps
rozmowy - 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ępnie
chgrp
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ępnychown
.W przypadku wywołania rekurencyjnego istnieją przypadki skrajne, w których całe przejście,
chgrp
po którym następuje całe przejście,chown
moż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żytkownikaalice
, skuteczną grupęstaff
i 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).źródło
chgrp
Lubchown
może mieć skutki uboczne, które wpływają na zdolność do drugiego. Na przykładchown
usuwa możliwośćchgrp
, to fakt.chgrp
usuwa bit setuid / setgid, może usunąć jakąś formę ACL lub inną formę kontekstu bezpieczeństwa ...chown
śledzeniechgrp
może zakończyć się niepowodzeniem, ale pytanie dotyczychgrp
odpowiedzichown
. Hmmm, kontekst bezpieczeństwa… może w systemie z obowiązkową kontrolą dostępuchgrp
może skazić plik i uniemożliwić jego przeglądanie? To wydaje się zbyt daleko idące.dir
, więc aby to zadziałało,chown
musiałoby najpierw przetworzyć głębokość plików i nie znam żadnej implementacji, która by to zrobiła. Jest to więc prawie prawidłowy przypadek, w którym chgrp + chown zawiódłby się tam, gdzie chmod u: g nie mógł, ale to tak naprawdę nie łączy się z tekstem uzasadnienia.chown
teorie wydają się być w konflikcie.