Hogyan működik a ragadós darab?

SUID

A ragadós bit et a futtatható programokra alkalmazták, amelyek megjelölték a rendszert, hogy megőrizzék a program képét a memóriában, miután a program futott.

De nem tudom, hogy mit tárolt a memóriában. És ebben az esetben hogyan láthatom őket?

Megjegyzések

Válasz

Ez valószínűleg az egyik legkellemetlenebb dolgom, amelyet az emberek állandóan elrontanak. A SUID / GUID bit és a sticky-bit két teljesen különböző dolog.

Ha egy man chmod -t csinál, akkor olvashat a SUID-ről és a sticky-bitekről. A man oldal itt is elérhető .

háttér

kivonat

A rwxXst betűk kiválasztják a fájlmód bitjeit a érintett felhasználók: olvasás (r), írás (w), végrehajtás (vagy könyvtárak keresése) (x), végrehajtás / keresés csak akkor, ha a fájl könyvtár vagy már rendelkezik végrehajtási engedéllyel néhány felhasználó számára (X), felhasználói vagy csoportazonosító beállítása végrehajtás (ok) , korlátozott törlési jelző vagy ragacsos bit ( t) .

SUID / GUID

Mi a fenti man oldal Azt akarom mondani, hogy az a helyzet, amelyet az x bit az rwxrwxrwx-ben elfoglal a felhasználó oktális (az rwx 1. csoportja) és az oktális csoport (az rwx 2. csoportja) számára, további állapotot vehet fel, ahol az x s-vé válik. Amikor ez bekövetkezik, akkor a fájl végrehajtásakor (ha egy program és nem csak egy shell szkript) a fájl tulajdonosának vagy csoportjának engedélyével fog futni.

Tehát ha a fájl a root tulajdonában van és a SUID bit be van kapcsolva, a program rootként fog futni. Még akkor is, ha rendes felhasználóként futtatja. Ugyanez vonatkozik a GUID bitre is.

kivonat

BEÁLLÍTOTT ÉS BEÁLLÍTOTT BITEK

A chmod törli a szokásos fájl set-group-ID bitjét, ha a fájl csoportazonosítója igen nem egyezik a felhasználó tényleges csoportazonosítójával vagy a felhasználó egyikének kiegészítő csoportazonosítójával, kivéve, ha a felhasználó rendelkezik megfelelő jogosultságokkal. További korlátozások a MODE vagy az RFILE set-user-ID és set-group-ID bitjeinek figyelmen kívül hagyását okozhatják. Ez a viselkedés az alapul szolgáló chmod rendszerhívás házirendjétől és funkcionalitásától függ. Ha kétségei vannak, ellenőrizze az alapul szolgáló rendszer viselkedését.

A chmod megőrzi a könyvtár set-user-ID és set-group-ID bitjeit, hacsak nem határozza meg kifejezetten az ellenkezőjét. A biteket szimbolikusan állíthatja be vagy törölheti. módok, mint az u + s és a gs, és a biteket numerikus módban állíthatja be (de nem törölheti).

SUID / GUID példák

no suid / guid – csak az rwxr-xr-x bitek vannak beállítva .

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

suid & felhasználó futtatható bitje engedélyezve (kisbetűs s) – az rwsr-xrx bitek be vannak állítva.

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

suid engedélyezve rwSr-xr-x be van állítva.

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

guid & csoport futtatható bitje engedélyezve (kisbetűk) – a bitek rwxr-sr-x be vannak állítva.

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

guid engedélyezve & futtatható bit letiltva (nagybetűvel S) – az rwxr-Sr-x bitek be vannak állítva.

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

ragadós bit

A másik kezét t névvel jelöljük, például a /tmp könyvtárral:

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

Ezt a bitet mindig “korlátozott törlési bitnek” kellett volna nevezni, tekintettel arra, amit valóban megfogalmaz. Ha ez a módbit engedélyezve van, akkor egy könyvtárat olyanná tesz, hogy a felhasználók csak azokon a fájlokon belüli & fájlokat törölhessék, amelyeknek a tulajdonosai.

kivonat

KORLÁTOZOTT TÖRLÉSI Zászló vagy VAGY BETÉT

A korlátozott törlés jelző vagy ragadós bit egyetlen bit, amelynek az értelmezés a fájltípustól függ. Könyvtárak esetében
megakadályozza a jogosulatlan felhasználókat abban, hogy eltávolítsanak vagy átnevezzenek egy fájlt a könyvtárból, hacsak nem a fájl vagy a könyvtár tulajdonosa; ezt hívják a könyvtár korlátozott törlési zászlójának, és gyakran megtalálható a világon írható könyvtárakban, mint például a / tmp.Néhány régebbi rendszeren használt rendes fájlok esetében a bit elmenti a program szöveges képét a csereeszközre, így futtatásakor gyorsabban betöltődik; ezt ragacsos bitnek hívják.

megjegyzések

  • Valójában a sticky-bit korábban alkalmazható volt a futtatható fájlokra, aminek következtében ezek az első betöltésük után swap-ban maradtak. sok felesleges lemez / hálózat (NFS) és CPU-használat a sokat használt programok számára. Azonban sem a Linux, sem a legtöbb (az összes?) Unix rendszer ezt már nem támogatja (eltávolították a kernelből). Ez ' s " sticky ", mert a futtatható fájl elakadt a swapban. Ezenkívül könyvtárakként használták, mint Ön leírja.
  • Valójában a " sokat használt vagy nagyon nagy " jobb leírás lenne. Ne feledje, hogy a főiskolám volt a Netscape webböngésző " ragacsos " HP-UX számítógépükön még 1995-ben. Olyan kicsi programok, amelyeket nagyon gyakran használtak (pl. A rendszer-parancsokat gyakran a cron futtatta), és a nagy programok (pl. Netscape) voltak a fő jelöltek, amelyeket " ragasztóvá kell tenni ". Mindkét esetben pazarló lenne a lemezekről / NFS-ről való folyamatos újratöltés.
  • A sticky-bit programok a RAM-ban maradtak, nem pedig swap-ban (kép betöltése egy swap fájlból nem ' t sokkal gyorsabban, mint egy fájlrendszer lemezéről történő betöltés). Olyan alapvető operációs rendszer szintű parancsok számára készült, mint a ls. Nyilvánvaló, hogy csak a superuser tudta beállítani a fájl ragadós bitjét. Kevésbé vált fontossá a virtuális memória és a megosztott könyvtárak bevezetése után, és főleg, hogy a személyhívók okosabbak lettek, és dinamikusan eldönthetik, mely oldalakat tartsák fenn.
  • És mivel a ragadós tulajdonságnak semmi értelme nem volt egy könyvtár számára, ugyanaz A jogosultsági maszk egy részét később értelmezték a könyvtárak hagyományos fájl-létrehozási szemantikájának módosítására.
  • @alexis: Eredetileg a ragacsos bit programokat felcserélték. Ez sokkal gyorsabb volt, mint a fájlrendszerből való olvasás, mert a cserefájlok olvasása összefüggő szektorok voltak, így többnyire aszinkron módon olvashatók. A korai fájlrendszerekkel nem voltak szektor " futási hosszúságok ", és a legtöbb korai fájlrendszer-illesztőprogram akkor is egy szektort olvasott, ha a szektorok történetesen egymás után következett. Úgy tűnt, hogy a PDP-40-nél a ragadós programok azonnal betöltődtek, míg a nem ragadós programok a szokásos másodikat vették igénybe. Azt hiszem, csak ed ragacsos voltunk.

Válasz

“A ragadós bit olyan futtatható programokra vonatkozik, amelyek megjelölik a rendszert, hogy a program képe a memóriában maradjon a program futtatása után.”

Úgy gondolom, hogy ezek meglehetősen elavult információk, ma a legtöbb modern Unix ezt figyelmen kívül hagyja. Linux alatt a ragadós bit csak a könyvtárakra vonatkozik. itt és a meglehetősen informatív Wikipedia cikk .

Mindenesetre ebben a régi viselkedésben a kép (csak a “kód”, nem pedig az adatokat) csak a virtuális memóriában – normál esetben felcserélve – tároltuk, a valós memóriában nem, hogy a következő alkalommal gyorsabban futtassuk őket.

Válasz

Mik azok a ragadós bitek?

A ragadós bit egy engedélybit, amely be van állítva azon a könyvtáron, amely csak a fájl tulajdonosát engedélyezi a t-n belül hat könyvtár vagy a root felhasználó a fájl törléséhez vagy átnevezéséhez. Egyetlen másik felhasználó sem rendelkezik a szükséges jogosultságokkal a más felhasználók által létrehozott fájl törléséhez.

Ez egy biztonsági intézkedés a kritikus mappák és azok tartalmának (alkönyvtárak és fájlok) törlésének elkerülésére, bár más felhasználók teljes engedélyek.

Megjegyzések

  • Ez ' nem stimmel: hu.wikipedia.org/wiki/Sticky_bit
  • @AB Számomra elég pontosnak tűnik, szinte az ön által idézett Wikpedia cikk elejének átfogalmazásáig. Mi a ' baj?
  • Azt mondanám, hogy a válasz hiányos. A " Sticky " azt is jelzi, hogy a futtatható fájl a cseretérben marad, hogy gyorsabban fusson. Ez már ókori történelem, de a régebbi fájlrendszerekben az illesztőprogramok egyszerre egy-egy szektort olvasnak, még akkor is, ha a szektorok egymás után következnek. Ez a nem ragadós futtatható fájlokat lassúvá tette, a ragadósságnak akkoriban nagyon sok értelme volt.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük