Cum funcționează bitul lipicios?

SUID

bitul lipicios aplicat programelor executabile care marchează sistemul pentru a păstra o imagine a programului în memorie după ce programul a terminat de rulat.

Dar nu știu că ceea ce este stocat în memorie. Și cum le pot vedea, în acest caz.?

Comentarii

Răspuns

Acesta este probabil unul dintre cele mai enervante lucruri pe care oamenii le încurcă tot timpul. Bitul SUID / GUID și bitul lipicios sunt 2 lucruri complet diferite.

Dacă faceți un man chmod puteți citi despre SUID și biturile lipicioase. Pagina manuală este disponibilă și aici .

fundal

extras

Literele rwxXst selectează biți mod fișier pentru utilizatori afectați: citiți (r), scrieți (w), executați (sau căutați directoare) (x), executați / căutați numai dacă fișierul este un director sau are deja permisiunea de executare pentru un anumit utilizator (X), setează ID-ul utilizatorului sau al grupului la execuție (e) , pavilion de ștergere restricționat sau bit lipicios ( t) .

SUID / GUID

Ce este pagina manuală de mai sus încercarea de a spune este că poziția pe care o ia bitul x în rwxrwxrwx pentru octalul utilizatorului (primul grup de rwx) și octalul grupului (al doilea grup de rwx) poate lua o stare suplimentară în care x devine s. Când se întâmplă acest fișier când este executat (dacă este un program și nu doar un script shell) va rula cu permisiunile proprietarului sau ale grupului fișierului.

Deci, dacă fișierul este deținut de root iar bitul SUID este pornit, programul va rula ca root. Chiar dacă îl executați ca utilizator obișnuit. Același lucru se aplică și bitului GUID.

extras

SETUID AND SETGID BITS

chmod șterge bitul set-group-ID al unui fișier obișnuit dacă ID-ul grupului fișierului face să nu se potrivească cu ID-ul de grup efectiv al utilizatorului sau cu unul dintre ID-urile de grup suplimentare ale utilizatorului, cu excepția cazului în care utilizatorul are privilegii adecvate. Restricții suplimentare pot face ca biții set-user-ID și set-group-ID ai MODE sau RFILE să fie ignorați. Acest comportament depinde de politica și funcționalitatea apelului de sistem chmod subiacent. Când aveți dubii, verificați comportamentul de bază al sistemului.

chmod păstrează biții set-user-ID și set-group-ID ai unui director, cu excepția cazului în care specificați în mod explicit altfel. Puteți seta sau șterge biții cu simbolic moduri precum u + s și gs și puteți seta (dar nu șterge) biții cu un mod numeric.

Exemple SUID / GUID

fără suid / guid – sunt setați doar biții rwxr-xr-x .

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

suid & bitul executabil al utilizatorului activat (minuscule) – biții rwsr-xrx sunt setați.

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

suid activat & bit executabil dezactivat (majusculă S) – biții rwSr-xr-x sunt setate.

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

guid & bitul executabil al grupului activat (minuscule) – biții rwxr-sr-x sunt setați.

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

guid activat & bit executabil dezactivat (majusculă S) – biții rwxr-Sr-x sunt setați.

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

bit lipicios

Bitul lipicios de pe cealaltă mână este notată ca t, cum ar fi cu directorul /tmp:

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

Acest bit ar fi trebuit să fie numit întotdeauna „bitul de ștergere restricționat”, dat fiind că „este ceea ce conotează cu adevărat. Când acest bit de mod este activat, creează un director astfel încât utilizatorii să poată șterge numai fișierele & directoare din care sunt proprietarii.

extras

DRAGUL DE ȘTERGERE RESTRICTAT SAU BIT STICKY

Steagul de ștergere restricționat sau bitul lipicios este un singur bit, al cărui interpretarea depinde de tipul de fișier. Pentru directoare, acesta împiedică utilizatorii neprivilegiați să elimine sau să redenumească un fișier din director, cu excepția cazului în care dețin fișierul sau directorul; aceasta se numește pavilion de ștergere restricționată pentru director și se găsește în mod obișnuit în directoare care pot fi scrise în lume, cum ar fi / tmp.Pentru fișierele obișnuite de pe unele sisteme mai vechi, bitul salvează imaginea text a programului pe dispozitivul swap, astfel încât acesta să se încarce mai repede la rulare; acesta se numește bit lipicios.

Comentarii

  • De fapt, bitul adeziv ar putea fi aplicat anterior executabilelor, ceea ce a făcut ca acestea să rămână în swap după ce au fost încărcate pentru prima dată. Acest lucru ar putea economisi o mulțime de utilizări inutile de disc / rețea (NFS) și CPU pentru programele care au fost utilizate mult. Cu toate acestea, nici Linux, nici majoritatea (toate?) Sistemele Unix nu mai suportă acest lucru (a fost eliminat din nucleu). Este ' s " lipicios ", deoarece executabilul s-a blocat în swap. În plus, a fost folosit pentru directoare ca descrieți.
  • De fapt, " mult folosit sau foarte mare " ar fi o descriere mai bună. Amintiți-vă că facultatea mea a avut browserul web Netscape ca " lipicios pe computerul lor HP-UX încă din 1995. Deci programe mici, care erau foarte des utilizate (de ex. comenzile de sistem rulate frecvent de cron) și programele mari (de exemplu, Netscape) au fost candidați de primă clasă " lipicios ". În ambele cazuri, reîncărcarea lor constantă de pe disc / NFS ar fi risipitoare.
  • Programele de biți lipici au fost menite să rămână rezidente în RAM, nu în swap (încărcarea unei imagini dintr-un fișier swap nu este ' t mult mai repede decât încărcarea acestuia de pe un disc de sistem de fișiere). A fost destinat comenzilor esențiale la nivel de sistem de operare, cum ar fi ls. Evident, numai superutilizatorul ar putea seta bitul lipicios pe un fișier. A devenit mai puțin important după introducerea memoriei virtuale și a bibliotecilor partajate și, mai ales că pagerele au devenit mai inteligente și pot decide în mod dinamic ce pagini să rămână rezidente. o parte din masca de permisiuni a fost mai târziu interpretată pentru a modifica semantica tradițională de creare a fișierelor pentru directoare. Acest lucru a fost mult mai rapid decât citirea din sistemul de fișiere, deoarece citirea imaginilor de fișiere swap erau sectoare adiacente și astfel puteau fi citite mai ales asincron. Cu primele sisteme de fișiere, nu existau secțiuni " lungimi de rulare " și majoritatea driverelor de sistem de fișiere timpurii citeau un sector la rând, chiar dacă sectoarele s-a întâmplat să fie consecutiv. Rezultatul pe un PDP-40 a fost că programele lipicioase păreau să se încarce instantaneu, în timp ce programele non-lipicioase aveau a doua sau două obișnuite. Cred că am avut doar ed lipicios.

Răspuns

„Bitul lipicios aplicat programelor executabile care marchează sistemul pentru a păstra o imagine a programului în memorie după ce programul a terminat de rulat.”

Cred că sunt informații destul de învechite, astăzi majoritatea Unixurilor moderne ignoră acest lucru. În Linux, bitul lipicios este relevant doar pentru directoare. Consultați aici și destul de informativ articolul Wikipedia .

Oricum, în acel comportament vechi imaginea (doar „codul”, nu datele) au fost păstrate doar în memoria virtuală – schimbată în mod normal, nu în memoria reală, pentru a o rula mai repede data viitoare.

Răspuns

Ce sunt biții lipicioși?

Un bit lipicios este un bit de permisiune setat pe un director care permite doar proprietarului fișierului din t directorul hat sau utilizatorul root pentru a șterge sau redenumi fișierul. Niciun alt utilizator nu are privilegiile necesare pentru a șterge fișierul creat de un alt utilizator.

Aceasta este o măsură de securitate pentru a evita ștergerea folderelor critice și a conținutului acestora (subdirectoare și fișiere), deși alți utilizatori au permisiuni complete.

Comentarii

  • Că ' nu este corect: en.wikipedia.org/wiki/Sticky_bit
  • @AB Mi se pare destul de exact, aproape până la punctul de parafrazare a începutului articolului Wikpedia pe care îl citați. Ce ' nu-i în regulă?
  • Aș spune că răspunsul este incomplet. " Sticky " denotă, de asemenea, că executabilul ar fi păstrat în spațiul swap pentru a-l rula mai repede. Acum, aceasta este o istorie veche, dar în driverele mai vechi de sisteme de fișiere se citeau câte un sector la un moment dat, chiar dacă sectoarele erau întâmplătoare. Acest lucru a făcut ca executabilele non-lipicioase să fie lente, lipiciul avea mult sens în acel moment.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *