Dlaczego setuid jest ignorowany w katalogach?


19

W systemach Linux możesz z powodzeniem chmod u+s $some_directory, ale zamiast wymuszać własność nowych podkatalogów i plików, aby być właścicielem katalogu zawierającego (i ustawiać również podkatalogi u+s), jak można się spodziewać, system po prostu ignoruje bit setuid. Podkatalogi i pliki nadal dziedziczą identyfikatory UID swoich procesów tworzenia, a podkatalogi nie są domyślnie skonfigurowane jako setuid.

Dlaczego setuid jest ignorowany w katalogach i jak mogę sprawić, by system go rozpoznał?


Zastanawiam się, czy opcja montowania „nosuid” może na to wpłynąć.
Heptyt

System plików, o którym mowa, nie jest zamontowany - nosuidchociaż istnieje inny (ramdysk /dev/shm), który / jest / zamontowany nosuid, i wydaje się, że traktuje setuidbit dokładnie w ten sam sposób. 6_9
Blacklight Shining


2
Jeśli chodzi o implementację, kod źródłowy Linuksa jest łatwo dostępny, możesz zaimplementować tę funkcję. Ponieważ już istnieje na FreeBSD, możesz dość łatwo skopiować kod, jestem pewien. Oczywiście te bity nadal nie miałyby znaczenia na czyimś systemie Linux.
mikebabcock

Odpowiedzi:


16

Przypomnij sobie, że bity setuid i setgid zostały wymyślone w zupełnie innym celu: spowodowanie uruchomienia pliku wykonywalnego z identyfikatorem użytkownika lub identyfikatorem użytkownika, a nie identyfikatorem użytkownika lub identyfikatora użytkownika uruchamiającego plik. Każde inne użycie jest tylko dodatkową funkcją.

Te bity nie działają w zwykłych plikach, które nie są wykonywalne. (A także skrypty powłoki w niektórych dystrybucjach, ze względu na problemy związane z bezpieczeństwem.) Początkowo nie miały one również funkcji katalogów. Oczywiście ktoś zdecydował, że fajnie byłoby wziąć nieużywany setgid do katalogów i użyć go do wymuszenia spójności własności grupy. W końcu, jeśli grasz z własnością grupy, dzieje się tak, ponieważ więcej niż jedna osoba pracuje z plikiem i prawdopodobnie ma sens, aby wszystkie pliki w danym katalogu należały do ​​tej samej grupy, bez względu na to, kto je utworzył. Problemy związane z zapominaniem o uruchomieniu newgrp są eliminowane.

Dlaczego więc nie wdrożyć tej samej funkcji dla setuid i UID pliku? Cóż, UID jest znacznie bardziej podstawowy niż GID. Jeśli to zaimplementujesz, często plik nie będzie należeć do użytkownika, który go utworzył! Prawdopodobnie użytkownik nadal może modyfikować plik (zakładając, że umask jest czymś rozsądnym), ale nie może zmienić bitów uprawnień. Trudno dostrzec użyteczność tego.


Chciałbym, aby został zaimplementowany, choćby ze względu na spójność… X3 W każdym razie, poza obejściem, takim jak cronjob, aby okresowo przeglądać i zmieniać własność, / czy jest jakiś sposób na wymuszenie własności pliku?
Blacklight Shining

4
Kusi mnie, by zacytować Emersona na temat głupiej spójności. Zanim przekonasz mnie, że jest to pożądana funkcja, musisz pokazać mi przypadek użycia, w którym ma to sens.
Isaac Rabinovitch

1
FreeBSD chmod (2) faktycznie dyskutuje na ten temat, ale wspomina tylko, że nie powinno się go generalnie używać z powodu nieokreślonych „luk bezpieczeństwa”. Podejrzewam, że większość innych Uniksów nie przyjęła tej funkcji, ponieważ chociaż ma kilka przypadków użycia, nie jest to tak bardzo przydatne.
jjlin

1
„Trudno dostrzec użyteczność tego” -> ustawionego w katalogu domowym, więc skrypty udostępniania działające jako root nie mogą zapomnieć o przypadkowym przejściu czegoś?
ufotds

1
uruchamianie skryptów superużytkowników w twoim katalogu domowym to naprawdę zły pomysł
Isaac Rabinovitch

7

Uważam, że odpowiedź na to pytanie dotyczy problemów związanych z bezpieczeństwem „rozdawania plików”, które spowodowały, że większość współczesnych systemów uniksowych nie pozwala na „rozdawanie plików”. „Rozdawanie plików” ma miejsce, gdy użytkownik niebędący superużytkownikiem zmienia własność pliku na osobę inną niż ten użytkownik. Ta zdolność daje wiele możliwości psot.

Ponieważ prezenty plików nie są dozwolone, setuid w katalogach, które pełnią tę samą funkcję w innej formie, nie jest dozwolony lub ignorowany, jeśli jest ustawiony.

Jeśli chodzi o zmianę zachowania, będziesz musiał zmodyfikować biblioteki i narzędzia systemu operacyjnego.


2

Jednym z bardzo dobrych przypadków zastosowania tego jest:

Załóżmy, że masz serwer z wieloma lokacjami i 3 bezpiecznymi witrynami. Utworzono 3 grupy, po jednej dla każdego z różnych opiekunów witryn. Wszystkie pliki we wszystkich witrynach muszą być własnością użytkownika apache, aby apache mógł je czytać i zapisywać (drupal / wordpress itp.).

Gdyby setuid działał jak bit setgid dla uprawnień do katalogów, wyglądałby mniej więcej tak:

/var/www/sitea - apache:groupa  rwS rwS ---
/var/www/siteb - apache:groupb  rwS rwS ---
/var/www/sitec - apache:groupc  rwS rwS ---

W ten sposób każda grupa opiekunów miała dostęp do przeglądania i dotykania tylko ich zawartości, ale apache użytkownika serwera WWW mógł obsługiwać całą zawartość i użytkownicy nie muszą się martwić o zmianę własności przesyłanych plików.

Innym przypadkiem jest Anonimowe przesyłanie ftp / http lub nawet sftp / ssh. Grupa i identyfikator GID w katalogu przesyłania będą rootem, podobnie jak właściciel i identyfikator UID. Inne uprawnienia byłyby -wx. Umożliwiłoby to wszystkim WRITE dostęp do katalogu wysyłania, ale nie mogliby niczego odczytać po przesłaniu, a root byłby właścicielem wszystkich nowo utworzonych plików.

Istnieją więc dwa całkowicie dobre i poprawne przypadki użycia umożliwiające włączenie funkcji UID w katalogach w celu dopasowania bitu GID.

Steven Mercurio


1
Wydaje się, że nie dotyczy to zadanego pytania.
Kevin Panko

2
@KevinPanko Nie, to nie odpowiada na moje pytanie. Witryna może nawet być nie na temat („po co jest to zastosowanie <nonexistent feature X>?”). Jednakże, nie odnoszą się do mojego pytania, a ja, jako pytającego, że okaże się przydatny.
Blacklight Shining

0

Trochę późno na imprezę, ale na wypadek, gdyby przyszli czytelnicy natknęli się na to;) Jak stwierdzili inni, w standardowym systemie plików OS-X setUID dla katalogów jest ignorowany - i wydaje się, że nie ma łatwego sposobu na obejście tego ( mount -o.... czy co nie). Jak często strona man nie jest zgodna z zachowaniem OS-X, które dosłownie stwierdza:

4000 (bit zestawu ID użytkownika przy wykonywaniu) [...] Katalogi z zestawem bitów ID użytkownika wymuszą, aby wszystkie utworzone w nich pliki i podkatalogi były własnością właściciela katalogu, a nie UID procesu tworzenia [...]

ale zawiera także listę możliwości osiągnięcia tego samego efektu bez rezygnacji z pierwotnej własności. Linux używa „[g /] setfacls” do podobnych efektów (uprawnienia te nie są tak naprawdę widoczne na pierwszy rzut oka, więc może być czasem uciążliwe).

Jeśli chodzi o „jak mogę osiągnąć podobne efekty”, przeczytaj całą stronę podręcznika i majstruj przy:

chmod +a 'guest allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' ./[DIRECTORY]

możesz to sprawdzić za pośrednictwem

ls -le

jeśli wszystko wygląda dobrze. Dalsze opcje obejmują wstawianie reguł w określonych pozycjach, usuwanie lub zastępowanie określonych reguł. Dwie warte uwagi opcje to „ file_inheriti directory_inherit” pozwalające na dołączenie reguł do nowego katalogu / pliku.

Nie przepadam za używaniem setUID, ale setGID jest bardzo przydatny na serwerach plików, gdzie po prostu ustawienie „głównej” grupy nie działa lub klienci mają maski plików uniemożliwiające zapis grupy. Rozwiązałoby to:

chmod +a 'mygroup allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /fileserver/groupfolders/mygroup

Witamy w Stack Exchange! To dobra odpowiedź, ale ponieważ odnosi się ona do OS X, a nie do dystrybucji Linuksa (które, jak wspomniałeś, używają innego systemu ACL), nie wydaje się to tutaj tak istotne. Zdecydowanie dobrze byłoby odpowiedzieć na pytanie, jak ustawić OS X na honorowanie katalogów setuid; może powinieneś zamieścić jeden ?
Blacklight Shining

Nawiasem mówiąc, fragment, który pominąłeś na stronie podręcznika OS X, chownwydaje się naprawdę ważny! „[…] Jeśli podstawowy system plików obsługuje tę funkcję: zobacz chmod (2) i opcję suiddir montowania (8).” Tak naprawdę nigdy wcześniej tego nie zauważyłem. Jeśli implementuje się HFS suiddir, można to zrobić na wspólnym systemie OS X.
Blacklight Shining

(I listy ACL dla OS X są tak „nie widoczne na pierwszy rzut oka”, jak listy ACL dla systemu Linux).
Blacklight Shining

0

Cóż, powinien przestrzegać standardu. Mogę myśleć w kilku scenariuszach z sftp-only, że zaoszczędziłoby mi to wiele kłopotów, zarówno z acl, jak i zestawem acl-mask, które robi sshd, i resetem, który muszę zrobić dla tej maski.

Domyślnie bezpieczeństwo jest dość przydatne, ale jeśli nie wybierzesz tej opcji, po prostu tworzysz winghtmare.

https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html

Tak czy inaczej, jest tak, jak teraz Linux, więc po prostu użyj acl's do obejścia tych.


-1

Według http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories bit setuid jest ignorowany dla katalogów w systemach UNIX i Linux. Możliwe jest jednak, aby działał zgodnie z oczekiwaniami na FreeBSD.


Nie jest pomocny - zapytałem, dlaczego setuidzostał zignorowany dla katalogów i czy można go rozpoznać w systemie Linux.
Blacklight Shining

Wydaje się oczywiste, że jest ignorowane w systemie Linux, ponieważ jest ignorowane w systemie Unix, co sprawia, że ​​poprawne zachowanie się systemu Linux w połączeniu z prawdziwym * nix Zapraszam do przeczytania tego artykułu. Ta sama odpowiedź na stronie greenend.org.uk/rjk/tech/perms.html z 2004 r., A także duplikat serverfault.com/questions/371541
mikebabcock

Dlaczego więc jest ignorowany w Uniksie?
Isaac Rabinovitch

@IsaacRabinovitch, odkąd Blacklight wyjaśnił, że pytanie dotyczy Linuksa, to nie jest istotne [język w policzek], ale podejrzewam, że jest to po prostu niezdefiniowane zachowanie, w którym wiele Uniksów robiło z nim różne rzeczy, a nie robienie niczego jest bezpieczniejszym założeniem.
mikebabcock

Pytanie / jest / oznaczone linux, tak, ale to nie znaczy, że wolę niejasne „To zrobiono w ten sposób, ponieważ inne systemy robią to w ten sposób” odpowiedź na odpowiedź, która wyjaśnia, dlaczego tak się dzieje w innych systemach. (Może linuxtag powinien zostać po prostu usunięty?)
Blacklight Shining
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.