Jak działa lepki bit?

SUID

bit sticky stosowany do programów wykonywalnych oznaczających system w celu zachowania obrazu programu w pamięci po zakończeniu działania programu.

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

Komentarze

Odpowiedź

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

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

tło

fragment

Litery rwxXst wybierz bity trybu pliku dla dotknięci użytkownicy: odczyt (r), zapis (w), wykonanie (lub wyszukiwanie katalogów) (x), wykonanie / wyszukiwanie tylko wtedy, gdy plik jest katalogiem lub ma już uprawnienia do wykonywania dla jakiegoś użytkownika (X), ustaw identyfikator użytkownika lub grupy podczas wykonywania , ograniczoną flagę usunięcia lub bit przyklejony ( t) .

SUID / GUID

Czym jest powyższa strona podręcznika próbuje powiedzieć, że pozycja, jaką zajmuje bit x w rwxrwxrwx użytkownika ósemkowego (pierwsza grupa rwx) i grupa ósemkowa (2. grupa rwx) może przyjąć dodatkowy stan, w którym x staje się s. W takim przypadku plik ten po wykonaniu (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 właścicielem pliku jest root a bit SUID jest włączony, program będzie działał jako root. Nawet jeśli wykonasz go jako zwykły użytkownik. To samo dotyczy bitu GUID.

fragment

BITY SETUID I SETGID

chmod czyści bit set-group-ID zwykłego pliku, jeśli identyfikator grupy pliku tak nie pasuje do efektywnego identyfikatora grupy użytkownika ani do jednego z dodatkowych identyfikatorów grup użytkownika, chyba że użytkownik ma odpowiednie uprawnienia. Dodatkowe ograniczenia mogą powodować ignorowanie bitów set-user-ID i set-group-ID trybu lub RFILE. To zachowanie zależy od zasad i funkcjonalności bazowego 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ą symbolicznych tryby takie jak u + s i gs, a bity można ustawić (ale nie wyczyścić) w trybie numerycznym.

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 & wykonywalny bit użytkownika włączone (małe litery) – bity rwsr-xrx są ustawione.

$ 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 & bit wykonywalny wyłączony (wielkie litery S) – bity rwSr-xr-x są ustawione.

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

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

$ 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 & bit wykonywalny wyłączony (wielkie litery S) – bity rwxr-Sr-x są ustawione.

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

Sticky bit

Sticky bit na druga ręka jest oznaczona jako t, na przykład w katalogu /tmp:

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

Ten bit powinien zawsze nazywać się „bitem ograniczonego usuwania”, biorąc pod uwagę, że to właśnie on oznacza. Gdy ten bit trybu jest włączony, tworzy katalog w taki sposób, że użytkownicy mogą usuwać tylko pliki & znajdujące się w nim katalogi, których są właścicielami.

fragment

FLAGA OGRANICZONEGO USUNIĘCIA LUB STICKY BIT

Ograniczona flaga usunięcia lub lepki bit to pojedynczy bit, którego interpretacja zależy od typu pliku. W przypadku katalogów
uniemożliwia nieuprzywilejowanym użytkownikom usunięcie lub zmianę nazwy pliku w katalogu, chyba że są właścicielami pliku lub katalogu; nazywa się to ograniczoną flagą usuwania katalogu i jest powszechnie spotykane w katalogach z możliwością zapisu na całym świecie, takich jak / tmp.W przypadku zwykłych plików w niektórych starszych systemach bit zapisuje obraz tekstu programu na urządzeniu do wymiany, więc ładuje się szybciej po uruchomieniu; nazywa się to bitem lepkim.

Komentarze

  • W rzeczywistości bit sticky mógł być wcześniej stosowany do plików wykonywalnych, co powodowało, że pozostawały one w zamianie po pierwszym załadowaniu. Mogło to zaoszczędzić wiele niepotrzebnych dysków / sieci (NFS) i użycie procesora przez programy, które były często używane. Jednak ani Linux, ani większość (wszystkie?) systemy Unix nie obsługują tego już (zostało usunięte z jądra). ' s " sticky ", ponieważ plik wykonywalny utknął w zamianie. Ponadto był używany dla katalogów jako opisujesz.
  • Właściwie " często używany lub bardzo duży " byłby lepszym opisem. Pamiętaj, że moja uczelnia miała przeglądarka internetowa Netscape jako " sticky " na swoim 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) były głównymi kandydatami do uczynienia " lepkimi ". W obu przypadkach ciągłe przeładowywanie ich z dysku / systemu plików NFS byłoby marnotrawstwem.
  • Programy z lepkimi bitami miały pozostawać rezydentne w pamięci RAM, a nie w wymianie (ładowanie obrazu z pliku wymiany nie jest ' t o wiele szybciej niż ładowanie z dysku systemu plików). Był przeznaczony dla podstawowych poleceń na poziomie systemu operacyjnego, takich jak ls. Oczywiście tylko superużytkownik może ustawić lepki bit w pliku. Stało się to mniej ważne po wprowadzeniu pamięci wirtualnej i bibliotek współdzielonych, a zwłaszcza gdy pagery stały się inteligentniejsze i mogą dynamicznie decydować, które strony mają pozostać rezydentne.
  • A ponieważ właściwość sticky nie miała sensu w przypadku katalogu, to samo bit maski uprawnień został później zinterpretowany w celu zmodyfikowania tradycyjnej semantyki tworzenia plików dla katalogów.
  • @alexis: Pierwotnie lepkie programy bitowe 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, więc można je było odczytywać głównie asynchronicznie. We wczesnych systemach plików nie było sektorów " długości przebiegu ", a większość wczesnych sterowników systemów plików odczytuje jeden sektor na raz, nawet jeśli sektory zdarzyło się następować po sobie. Rezultatem na PDP-40 było to, że lepkie programy wydawały się ładować natychmiast, podczas gdy programy nieklejące zajmowały zwykle sekundę lub dwie. Myślę, że mieliśmy tylko ed przyklejony.

Odpowiedź

„Lepki bit stosowany do programów wykonywalnych oznaczający 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 bit „sticky” ma znaczenie tylko dla katalogów. Zobacz tutaj i dość pouczający artykuł w Wikipedii .

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

Odpowiedź

Co to są bity lepkie?

Sticky bit to ustawiony bit pozwolenia w katalogu, który zezwala tylko właścicielowi pliku w ciągu t hat lub użytkownika root, aby usunąć lub zmienić nazwę pliku. Żaden inny użytkownik nie ma wymaganych uprawnień do usunięcia pliku utworzonego przez innego użytkownika.

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

Komentarze

  • To ' nie jest poprawne: en.wikipedia.org/wiki/Sticky_bit
  • @AB Wydaje mi się, że jest to całkiem trafne, prawie do tego stopnia, że parafrazuje początek cytowanego przez ciebie artykułu Wikpedii. Co ' jest w nim nie tak?
  • Powiedziałbym, że odpowiedź jest niekompletna. " Przyklejony " oznacza również, że plik wykonywalny byłby przechowywany w przestrzeni wymiany, aby działał szybciej. To już starożytna historia, ale w starszych systemach plików sterowniki czytały jeden sektor na raz, nawet jeśli były to kolejne. To spowodowało, że nieklejące się pliki wykonywalne były powolne, a lepkość miała wtedy duży sens.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *