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
- Itt egy jó bemutató bemutatott példákkal és magyarázatokkal. Ennek megértésének kulcsa az érintett oktális rendszer. Linux Öntapadó bitek bemutatója bemutatott példákkal .
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.