Jak działa bit lepki?

148

SUID

Lepki nieco zastosowane do programów wykonywalnych słabnącym systemu, aby mieć obraz programu w pamięci po zakończeniu działania programu.

Ale nie wiem, co jest przechowywane w pamięci. I jak mogę je zobaczyć w tym przypadku.?

filesystems permissions fluke-ng
źródło
Oto dobry samouczek z działającymi przykładami i objaśnieniami. Kluczem do zrozumienia tego jest system ósemkowy. Linux Sticky Bits Tutorial z działającymi przykładami .
CMP

Odpowiedzi:

193

Jest to prawdopodobnie jedna z moich najbardziej irytujących rzeczy, które ludzie cały czas psują. Bit SUID / GUID i bit lepki to 2 zupełnie różne rzeczy.

Jeśli to zrobisz man chmod, możesz przeczytać o SUID i lepkich bitach. Strona podręcznika jest również dostępna tutaj .

tło

fragment

Litery rwxXst wybierają bity trybu pliku dla dotkniętych użytkowników: odczyt (r), zapis (w), wykonanie (lub wyszukiwanie katalogów) (x), wykonanie / wyszukiwanie tylko, jeśli plik jest katalogiem lub ma już uprawnienia do wykonywania dla niektórych użytkownik (X), ustaw ID użytkownika lub grupy na wykonanie (s) , flagę ograniczonego usuwania lub lepki bit (t) .

SUID / GUID

Powyższa strona podręcznika próbuje powiedzieć, że pozycja, którą bit x zajmuje w rwxrwxrwx dla ósemki użytkownika (1. grupa rwx), a ósemka grupy (2. grupa rwx) może przyjąć dodatkowy stan, w którym x staje się s. Kiedy to nastąpi, ten plik po uruchomieniu (jeśli jest to program, a nie tylko skrypt powłoki) będzie działał z uprawnieniami właściciela lub grupy pliku.

Więc jeśli plik jest własnością root, a bit SUID jest włączony, program będzie działał jako root. Nawet jeśli wykonujesz go jako zwykły użytkownik. To samo dotyczy bitu GUID.

fragment

SETUID I SETGID BITS

chmod usuwa bit set-group-ID zwykłego pliku, jeśli identyfikator grupy pliku nie odpowiada efektywnemu identyfikatorowi grupy użytkownika lub jednemu z dodatkowych identyfikatorów grupy użytkownika, chyba że użytkownik ma odpowiednie uprawnienia. Dodatkowe ograniczenia mogą powodować, że bity SET-user-ID i set-group-ID MODE lub RFILE będą ignorowane. To zachowanie zależy od zasad i funkcjonalności wywołania systemowego chmod. W razie wątpliwości sprawdź podstawowe zachowanie systemu.

chmod zachowuje bity set-user-ID i set-group-ID katalogu, chyba że wyraźnie określono inaczej. Możesz ustawić lub wyczyścić bity za pomocą trybów symbolicznych, takich jak u + s i gs, i możesz ustawić (ale nie wyczyścić) bity za pomocą trybu numerycznego.

Przykłady SUID / GUID

no suid / guid - ustawione są tylko bity rwxr-xr-x .

$ ls -lt b.pl
-rwxr-xr-x 1 root root 179 Jan  9 01:01 b.pl

suid i bit wykonywalny użytkownika włączony (małe litery s) - ustawione są bity rwsr-xrx .

$ chmod u+s b.pl 
$ ls -lt b.pl 
-rwsr-xr-x 1 root root 179 Jan  9 01:01 b.pl

suid włączony i wyłączony bit wykonywalny (wielkie litery S) - ustawione są bity rwSr-xr-x .

$ chmod u-x b.pl
$ ls -lt b.pl 
-rwSr-xr-x 1 root root 179 Jan  9 01:01 b.pl

włączony bit wykonywalny guid & group (małe litery s) - ustawione są bity rwxr-sr-x .

$ chmod g+s b.pl
$  ls -lt b.pl 
-rwxr-sr-x 1 root root 179 Jan  9 01:01 b.pl

GUID włączony i wyłączony bit wykonywalny (wielkie litery S) - ustawione są bity rwxr-Sr-x .

$ chmod g-x b.pl
$  ls -lt b.pl 
-rwxr-Sr-x 1 root root 179 Jan  9 01:01 b.pl

lepki kawałek

Z drugiej strony lepki bit jest oznaczony jako t, na przykład w /tmpkatalogu:

$ ls -l /|grep tmp
drwxrwxrwt. 168 root root 28672 Jun 14 08:36 tmp

Ten bit powinien być zawsze nazywany „bitem ograniczonego usuwania”, biorąc pod uwagę, że tak właśnie się kojarzy. Gdy bit tego trybu jest włączony, tworzy katalog, w którym użytkownicy mogą usuwać tylko pliki i katalogi w nim, których są właścicielami.

fragment

OGRANICZONA USUWANIE FLAGI LUB KLEJOWEGO BITU

Flaga ograniczonego usuwania lub lepki bit to pojedynczy bit, którego interpretacja zależy od typu pliku. W przypadku katalogów
uniemożliwia nieuprzywilejowanym użytkownikom usuwanie lub zmianę nazwy pliku w katalogu, chyba że jest on właścicielem pliku lub katalogu; nazywa się to flagą ograniczonego usuwania katalogu i jest powszechnie spotykane w światowych katalogach takich jak / tmp. W przypadku zwykłych plików w niektórych starszych systemach bit zapisuje obraz tekstowy programu na urządzeniu wymiany, aby ładował się szybciej po uruchomieniu; nazywa się to lepkim bitem.

slm
źródło
43
W rzeczywistości bit lepki można było wcześniej zastosować do plików wykonywalnych, co powodowało, że pozostawały one w wymianie po pierwszym załadowaniu. Może to zaoszczędzić wiele niepotrzebnego użycia dysku / sieci (NFS) i procesora dla programów, które były często używane. Jednak ani Linux, ani większość (wszystkich?) Systemów uniksowych już tego nie obsługuje (został usunięty z jądra). Jest „lepki”, ponieważ plik wykonywalny utknął w swapie. Ponadto został wykorzystany do katalogów, jak opisano.
Baard Kopperud
4
Właściwie „lepiej używany lub bardzo duży” byłby lepszym opisem. Pamiętaj, że moja uczelnia miała przeglądarkę internetową Netscape jako „lepką” na komputerze HP-UX w 1995 roku. Tak małe programy, które były bardzo często używane (np. Polecenia systemowe uruchamiane często przez crona) i duże programy (np. Netscape) byli głównymi kandydatami do „lepkości”. W obu przypadkach ciągłe przeładowywanie ich z dysku / NFS byłoby marnotrawstwem.
Baard Kopperud
8
Programy lepkie miały pozostać w pamięci RAM, a nie w trybie wymiany (ładowanie obrazu z pliku wymiany nie jest o wiele szybsze niż ładowanie z dysku systemu plików). Był przeznaczony do podstawowych poleceń na poziomie systemu operacyjnego, takich jak ls. Oczywiście tylko administrator może ustawić lepki bit na pliku. Stało się to mniej ważne po wprowadzeniu pamięci wirtualnej i bibliotek współdzielonych, a zwłaszcza, gdy pager stał się mądrzejszy i może dynamicznie decydować, które strony zachować.
Alexis
4
A ponieważ lepka właściwość nie miała sensu dla katalogu, ten sam bit maski uprawnień został później zinterpretowany w celu zmodyfikowania tradycyjnej semantyki tworzenia plików dla katalogów.
Alexis
5
@alexis: Początkowo programy z lepkimi bitami były przechowywane w przestrzeni wymiany. Było to znacznie szybsze niż czytanie z systemu plików, ponieważ odczytywanie obrazów plików wymiany było ciągłymi sektorami i dlatego można było je czytać głównie asynchronicznie. We wczesnych systemach plików nie było „długości uruchomień” sektora, a większość wczesnych sterowników systemu plików odczytywała jeden sektor na raz, nawet jeśli sektory były kolejne. Rezultatem na PDP-40 było to, że programy lepkie wydawały się ładować natychmiast, podczas gdy programy nielepkie zajmowały zwykle sekundę lub dwa. Myślę, że mieliśmy tylko edklej.
wallyk
8

„Bit lepki zastosowany do programów wykonywalnych oznaczających system, aby zachować obraz programu w pamięci po zakończeniu działania programu.”

Myślę, że to dość przestarzałe informacje, dziś większość współczesnych Uniksów to ignoruje. W Linuksie lepki bit dotyczy tylko katalogów. Zobacz tutaj i dość pouczający artykuł z Wikipedii .

W każdym razie, w tym starym zachowaniu obraz (tylko „kod”, nie dane) był przechowywany tylko w pamięci wirtualnej - normalnie zamieniany, a nie w prawdziwej pamięci, aby następnym razem uruchomić go szybciej.

leonbloy
źródło
3

Co to są lepkie bity?

Lepki bit to bit uprawnień ustawiony w katalogu, który pozwala tylko właścicielowi pliku w tym katalogu lub użytkownikowi root na usunięcie lub zmianę nazwy pliku. Żaden inny użytkownik nie ma wymaganych uprawnień do usunięcia pliku utworzonego przez innego użytkownika.

Jest to środek bezpieczeństwa, aby uniknąć usunięcia krytycznych folderów i ich zawartości (podkatalogów i plików), chociaż inni użytkownicy mają pełne uprawnienia.

chandrakumar.M
źródło
1
To nie w porządku: en.wikipedia.org/wiki/Sticky_bit
AB
7
@AB Wydaje mi się to dość dokładne, niemal do sparafrazowania początku cytowanego artykułu Wikpedia. Co jest z tym nie tak?
roaima,
Powiedziałbym, że odpowiedź jest niepełna. „Przyklejony” oznacza również, że plik wykonywalny będzie przechowywany w przestrzeni wymiany, aby przyspieszyć jego działanie. To starożytna historia, ale w starszych systemach plików sterowniki odczytywały jeden sektor na raz, nawet jeśli sektory były kolejne. Powodowało to, że nielepkie pliki wykonywalne działały wolno, a lepkość miała wtedy sens.
GhostCode