Care este nevoia comenzii `fakeroot` în linux

Imaginați-vă că sunteți un dezvoltator / menținător de pachete etc. care lucrează pe un server la distanță. Doriți să actualizați conținutul unui pachet și să îl reconstruiți, să descărcați și să personalizați un kernel de pe kernel.org și să îl construiți, etc. În timp ce încercați să faceți aceste lucruri, veți afla că unii pași necesită să aveți root drepturi (UID și GID 0) din diferite motive (securitate, permisiuni trecute cu vederea etc.). Dar nu este posibil să obțineți drepturi root, deoarece lucrați la o mașină la distanță (și mulți alți utilizatori au aceeași problemă ca dvs.). Aceasta este exact ceea ce face: pretinde că un UID și GID eficient este 0 pentru mediul în care le necesită.

În practică nu primiți niciodată privilegii reale root (în opoziție cu su și sudo pe care îl menționați).

Comentarii

• deci, nu pot ‘ să folosesc pentru a modifica setările sistemului ?? cuz comanda pe care o vom executa ‘ va crede că ‘ rulează ca root și va face tot ce vrem să facă. a câștigat ‘ nu?
• @mrid Rețineți ” În practică nu obțineți niciodată privilegii reale de root „. Deci, răspunsul nu este

Pentru a vedea clar diferența dintre fakeroot și un sudo / su real, pur și simplu faceți:

$ fakeroot # echo "Wow I have root access" > root.tst # ls -l root.tst -rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst # ls -l /root ls: cannot open directory /root: Permission denied # exit $ ls -l root.tst -rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst 

Atâta timp cât vă aflați în shell-ul fakeroot, se pare că sunteți root – atâta timp cât nu încercați să faceți nimic asta chiar are nevoie de privilegii de root. Și exact acest lucru are nevoie un instrument de ambalare pentru a face pachete care să aibă sens pe orice mașină.

De fapt, atunci când utilizați fakeroot pentru ambalare, ceea ce doriți să realizați este să creați instrumentele pe care le executați sub fakeroot pentru a vă vedea fișierele deținute de root. Nimic mai mult, nimic mai puțin. De fapt, su sau sudo nu vor funcționa pentru a obține dreptul de proprietate asupra fișierului.

Comentarii

• Nu este falsificatorul periculos? Dacă creez un fișier cu bitul suid și perm rx, fișierul va fi creat deținut de root, executabil de oricine, ca root! Sau poate setarea bitului suid nu va funcționa?
• Nu este bine. Am încercat eu asta. Motivul principal pentru fakeroot este obținerea rădăcinii de proprietate: rădăcină în pachetele construite fără a fi de fapt rădăcină. Totuși, pachetele instalate vor avea permisiuni adecvate.
• Totul a fost foarte derutant până când am citit comentariul lui @ ntzrmtthihu777 ‘!
• Ne pare rău, Nu ‘ nu înțeleg descrierea. De ce să nu corecți instrumentele, astfel încât să nu „02ddd2c2dd”>

Deoarece răspunsurile sunt greu de înțeles (pentru mine) și mi-a trebuit să mă gândesc să îl înțeleg ( acest comentariu m-a făcut să îl înțeleg), eu „m va oferi o explicație mai bună, sperăm.

1. Ce se întâmplă în fakeroot

Nimic mai mult decât ceea ce se întâmplă cu propriul dvs. utilizator. Absolut nimic mai mult. Dacă fakeroot (care, atunci când este apelat, vă oferă un shell nou, cum ar face sudo), prefaceți-vă că faceți lucruri pentru care aveți nevoie de permisiune și ieșiți, nu se va întâmpla absolut nimic.

Dacă vă gândiți la asta, este o pierdere totală de timp. De ce ai face lucruri care nu se vor întâmpla? Este o nebunie. Pur și simplu nu ai fi putut face nimic și nu ar fi existat nicio diferență, deoarece nu există nici o urmă.

Așteaptă un minut …

2. Urmărește de fakeroot

Ar putea să rămână o urmă din fakeroot. Să vedem comenzile din MortenSickel , care este destul de drăguț și merită un vot pozitiv:

$ fakeroot # echo "Wow I have root access" > root.tst # ls -l root.tst -rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst # ls -l /root ls: cannot open directory /root: Permission denied # exit $ ls -l root.tst -rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst 

La prima vedere, pare utilizarea fakeroot a fost o pierdere totală de timp. În cele din urmă, dacă nu ați fi folosit fakeroot, ați fi primit același lucru lucru.

Lucrul subtil aici este acesta:

$ cat root.tst Wow I have root access 

Ceea ce înseamnă că conținutul fișierului își amintește încă că este o rădăcină. S-ar putea spune că neutilizarea fakeroot ar fi produs aceleași rezultate. Ai dreptate, acest exemplu este prea simplu.

Să luăm un alt exemplu:

$ fakeroot # touch x # touch y # chown myuser:myuser x # ls -l > listing # exit $ ls -l total 4 -rw-rw-r-- 1 myuser myuser 152 Jan 7 21:39 listing -rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 x -rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 y $ cat listing total 0 -rw-rw-r-- 1 root root 0 Jan 7 21:39 listing -rw-rw-r-- 1 myuser myuser 0 Jan 7 21:39 x -rw-rw-r-- 1 root root 0 Jan 7 21:39 y 

Să vedem ce s-a întâmplat. M-am prefăcut că sunt root, ceea ce este total ineficient și am creat x și y. M-am prefăcut x că aparțin myuser și y că aparțin root. De fapt, ambii aparțin myuser (așa cum putem vedea în cele din urmă), dar eu doar am prefăcut că este așa.

Apoi am creat o listă și mi-am salvat imaginația într-un fișier. Mai târziu, când mă uit înapoi la fișier, pot vedea cine mi-am imaginat că ar trebui să dețină fișierele. Din nou, ele nu sunt deținute de oameni pe care mi-i imaginam, pur și simplu mi-am imaginat asta.

3. Deci … De ce vreți asta din nou?

S-ar putea să spuneți că nu trebuia să falsific să fiu rădăcină pentru a crea acea listă. Aș fi putut crea listarea, apoi să o editez pentru a reflecta imaginația mea. Ai dreptate, nu ai nevoie de fakeroot pentru asta. De fapt, știind că fakeroot nu face de fapt nimic, este posibil să nu fi câștigat vreo abilitate pe care nu o aveți înainte.

Dar , și despre asta este vorba fakeroot, modificarea listării ar putea fi netivială.Așa cum se întâmplă cu un pachet care poate fi instalat pe sistemul dvs., aveți un tar ed, gzip ed, xz ed, bzip2 ed sau orice alt format care vă păstrează fișierele împreună și își amintește permisiunile și proprietarii. Puteți modifica cu ușurință fișierul comprimat și puteți modifica proprietatea asupra unui fișier? Nu știu despre tine, dar nu mă pot gândi la o cale.

Ar putea exista un instrument care, odată ce totul este comprimat, modifică fișierul comprimat și editează programatic proprietățile și permisiunile? ? Da, s-ar putea. Deci, fie ați putea falsifica proprietățile înainte de a le comprima, fie le puteți schimba după. Oamenii Debian au decis că primul este mai ușor.

4. De ce nu folosiți doar sudo?

În primul rând, nu aveți nevoie de privilegii de root pentru a construi software și nu aveți nevoie de privilegii de root pentru a le comprima. Deci, dacă nu aveți nevoie de el, ar trebui să fiți cu adevărat un utilizator Windows pentru a vă gândi chiar să obțineți această permisiune. Dar sarcasmul deoparte, este posibil să nu aveți nici măcar o parolă de root.

În plus, să spunem că aveți permisiuni de root. Și să spunem că doriți să pretindeți că un fișier ar trebui să aibă acces de citire numai la rădăcină. Deci, sudo, schimbați proprietarul fișierului și permisiunile în root, ieșiți din shell-ul rădăcină și încercați să împachetați totul. Eșuați, deoarece acum nu mai puteți citi fișierul, deoarece nu aveți acces root. Deci, trebuie să sudo și să comprimați și să construiți pachetul ca root. Efectiv, trebuie să faceți totul ca rădăcină.

Acest lucru este rău ^TM .

În calitate de pachet, nu aveți nevoie de permisiuni de root și nu ar trebui să le obțineți. Când instalați un pachet, poate fi necesar să instalați un fișier (A) ca root și acolo unde aveți nevoie de permisiuni root. Tot ceea ce face fakeroot este să facă acest lucru posibil. Acesta permite ca lista de ambalaje A să fie deținută de root pentru arhivator, astfel încât atunci când pachetul este decomprimat de utilizator, arhivatorul solicită permisiunea root și creează A deținut de root.

Comentarii

• Scriere excelentă, acest lucru este clar.
• So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier. Acest lucru m-a ajutat în timp ce mă tot gândeam ‘ de ce să nu-l modific după? ‘.
• Mulțumesc, acest lucru clarifică confuzia pe care am avut-o după ce am citit răspunsul lui @Morten ‘

AFAIK, fakeroot execută o comandă într-un mediu în care pare să aibă privilegii de rădăcină pentru manipularea fișierelor. Acest lucru este util pentru a permite utilizatorilor să creeze arhive (tar, ar, .deb etc.) cu fișiere în ele cu permisiuni / proprietate root. Fără fakeroot, ar trebui să aveți privilegii root pentru a crea fișierele constitutive ale arhivelor cu permisiunile și proprietatea corecte, apoi să le împachetați, sau ar trebui să construiți arhivele direct, fără a utiliza arhivatorul.

fakeroot funcționează prin înlocuirea funcțiilor bibliotecii de manipulare a fișierelor (chmod (), stat () etc.) cu unele care simulează efectul pe care ar fi avut-o funcțiile reale ale bibliotecii, dacă utilizatorul ar fi fost cu adevărat root.

Sinopsis:

 fakeroot [-l|--lib library] [--faked faked-binary] [--] [command] 

Verificați mai multe aici: fakeroot

Comentarii

• @MaskTheSmokin: Deci, fakeroot vă oferă puterea super utilizatorului doar pentru operațiile de manipulare a fișierelor, nu.
• Nu prea oferă putere super utilizator, o preface doar – programul care rulează în el crede că are privilegii de root, în timp ce într-adevăr folosește încă privilegiile normale ale utilizatorului ‘.
• Unde este diferența dintre the program running in it thinks it has root privileges și programul care are privilegii de root? Dacă pot face un rm -rf / și programul, rularea lui consideră că am privilegii de root …
• @userunknown S-ar putea să ocoliți rm ‘ verifică dacă ai suficiente permisiuni, dar nucleul în sine nu ți-ar permite ‘ să te lase să o faci ; apelul de sistem unlink ar eșua. ‘ nu depinde doar de aplicație pentru a gestiona permisiunile, sau ‘ puteți scrie propria aplicație care nu ‘ nu verificați permisiunile și faceți orice doriți cu el
• Un exemplu pentru a elucida necesitatea fakeroot ar fi fantastic. Pot vedea utilizările fakeroot, dar nu ‘ nu văd de ce oamenii nu pot ‘ să lucreze în jurul permisiunilor root până la punctul în care ‘ este mai ușor de falsificat.

L-am folosit pentru scripturile de construire a pachetelor. Nu eram sigur că persoana care execută script-ul are acces la nivel de root, dar script-ul a fost încă necesar pentru a genera, să zicem, un fișier tar care conținea fișiere care aparțin root-ului. fișierele aparțin rădăcinii și le-au împachetat ca atare în interiorul arhivei. În acest fel, când pachetul a fost despachetat la mașina de destinație (pe o altă mașină cu totul), fișierele nu aparțineau utilizatorilor ciudați sau inexistenți.

Gândindu-mă la asta, singurul loc pe care l-am văzut a fost pentru construirea unui fel de arhivă: rootf-uri ale sistemelor încorporate, arhive tar.gz, pachete rpm, pachete .deb etc.

Comentarii

• fakeroot este un instrument de soluție pentru software-ul de ambalare eronat: nu există niciun motiv pentru care trebuie să fii root pentru a crea astfel de pachete, b de vreme ce nu ‘ vă permit să specificați permisiunile de fișiere în alt mod decât să le setați direct în sistemul de fișiere, nu aveți de ales

O utilizare obișnuită este de a afla la ce fișiere a vrut să acceseze într-adevăr un binar care nu reușea. Adică, aflarea și rezolvarea sau rezolvarea erorilor cauzate de căile codate greu și de gestionarea necorespunzătoare a excepțiilor.

Puteți folosiți fakeroot fără a avea de fapt privilegii de root. Dacă ați avea su și / sau sudo ați putea să vă distrugeți sistemul cu un simplu rm -rf /, dar cu fakeroot cel mult ați elimina directorul dvs. de pornire.

Comentarii

• Asta nu ‘ t explica necesitatea fakeroot. Puteți elimina directorul dvs. de acasă ca și dumneavoastră.

Răspunsul simplu:

comenzi su și sudo rulează ca root. fakeroot nu, în afara aranjamentului său parțial de nisip.