Hva er behovet for `fakeroot`-kommando i linux

Tenk deg at du er en utvikler / pakkeholder osv. som jobber på en ekstern server. Du vil oppdatere innholdet i en pakke og bygge den opp på nytt, laste ned og tilpasse en kjerne fra kernel.org og bygge den osv. Mens du prøver å gjøre disse tingene, vil du finne ut at noen trinn krever at du har root rettigheter (UID og GID 0) av forskjellige årsaker (sikkerhet, oversett tillatelser osv.). Men det er ikke mulig å få root rettigheter, siden du jobber på en ekstern maskin (og mange andre brukere har det samme problemet som deg). Dette er akkurat fakeroot gjør: det later som en effektiv UID og GID på 0 til miljøet som krever dem.

I praksis får du aldri reelle root privilegier (i motsatt retning av su og sudo som du nevner).

Kommentarer

• så jeg kan ‘ t bruke for å endre systeminnstillinger ?? cuz kommandoen vi ‘ vil kjøre vil tro at den ‘ kjører som root og gjør hva vi vil at den skal gjøre. vant ‘ t det?
• @mrid Vær oppmerksom på » I praksis får du aldri reelle rotprivilegier «. Så anwser er nei

For å se tydelig forskjellen mellom fakeroot og en ekte sudo / su, bare gjør:

$ 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 

Så lenge du er innenfor fakeroot-skallet, ser det ut som om du er rot – så lenge du ikke prøver å gjøre noe som virkelig trenger rotprivilegier. Og dette er nøyaktig hva et emballasjeverktøy trenger for å lage pakker som gir mening på enhver maskin.

Når du bruker fakeroot for emballasje, er det du vil oppnå å lage verktøyene du kjører under fakeroot for å se filene dine eies av root. Intet mer, intet mindre. Så faktisk, su eller sudo fungerer ikke for å få riktig fil eierskap.

Kommentarer

• Er ikke falskere farlig? Hvis jeg oppretter en fil med suid-biten og rx-perm, vil filen bli opprettet eid av root, kjørbar av alle, som root! Eller kanskje innstilling av suid-bit ikke fungerer?
• Ikke bra. Jeg prøvde dette selv. Hovedårsaken til fakeroot er å få eierskap root: rot til innebygde pakker uten å være root. installerte pakker vil ha skikkelig tillatelse.
• Alt var veldig forvirrende før jeg leste @ ntzrmtthihu777 ‘ s kommentar!
• Beklager, Jeg forstår ikke ‘ beskrivelsen. Hvorfor ikke lappe verktøyene slik at de ikke ‘ t klager hvis du ikke er rot? Som et relatert spørsmål: Tross alt er filene du oppretter under fakeroot, ikke faktisk eid av root. Ville ‘ ikke dette innebære at når jeg installerer en slik .deb -fil, alle mine /usr filene eies av den brukeren som kaller fakeroot?
• @ JohannesSchaub-litb, nei det er ‘ poenget. Filene eies ikke av root, men inne i et fakeroot skall ser de ut som de er. Når .deb-pakken er opprettet i dette skallet, blir fileieren lest fra filsystemet (som fakeroot avlytter og returnerer root) og lagres i pakken. Når du installerer pakken, krever dpkg deretter root-tilgang fordi pakken indikerer at filen skal eies av root.

Siden svarene er vanskelige å forstå (for meg selv) og det tok noen tanker å forstå det ( denne kommentaren fikk meg til å forstå det), jeg «m kommer til å gi en forhåpentligvis bedre forklaring.

1. Hva skjer i fakeroot

Ingenting mer enn hva som skjer med din egen bruker. Absolutt ingenting mer. Hvis du fakeroot (som når du ringer gir deg et nytt skall, som sudo ville), later til å gjøre ting du trengte tillatelse til, og avslutte, absolutt ingenting ville skje.

Hvis du tenker på det, er det totalt bortkastet tid. Hvorfor ville du gjøre ting som ikke faktisk vil skje? Det er vanvittig. Du kunne rett og slett ikke ha gjort noe av det, og det hadde ikke vært noen forskjell, siden det ikke er noe spor av det.

Vent litt …

2. Sporet av fakeroot

Det kan være et spor igjen av fakeroot. La oss se på kommandoene i MortenSickels svar som er ganske hyggelig og fortjener en oppstemning:

$ 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 

Ved første øyekast ser det ut som å ha brukt fakeroot var totalt bortkastet tid. Til slutt, hvis du ikke hadde brukt fakeroot, ville du ha fått det samme ting.

Den subtile tingen her er dette:

$ cat root.tst Wow I have root access 

Hvilket betyr at innholdet i filen fortsatt husker å være en rot. Du kan si at ikke å bruke fakeroot ville ha gitt de samme resultatene. Du har rett, dette eksemplet er for enkelt.

La oss ta et annet eksempel:

$ 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 

La oss se hva som skjedde. Jeg lot som om jeg var root, som er totalt ineffektiv, og opprettet x og y. Jeg lot som x å tilhøre myuser og y å tilhøre root. De tilhører faktisk begge myuser (som vi til slutt kan se), men jeg bare lot det være slik.

Så opprettet jeg en oppføring og lagret fantasien til en fil. Senere når jeg ser tilbake på filen, kan jeg se hvem jeg forestilte meg at filene skulle eies av. Igjen, de eies faktisk ikke av mennesker jeg forestilte meg, jeg bare forestilte meg det.

3. Så … Hvorfor vil du ha det igjen?

Du kan kanskje si at jeg ikke virkelig trengte å forfalske å være root for å opprette den oppføringen. Jeg kunne ganske enkelt ha opprettet oppføringen og redigert den for å gjenspeile min fantasi. Du har rett, du trengte ikke fakeroot for det. Vel vitende om at fakeroot ikke gjør noe, kan du muligens ha oppnådd enhver evne du ikke hadde før.

Men , og det er dette fakeroot handler om, redigering av oppføringen kan være lite viktig.Som det er med en pakke som kan installeres på systemet ditt, har du en tar ed, gzip ed, xz ed, bzip2 ed eller et annet format som holder filene dine sammen og husker deres tillatelser og eiere. Kan du enkelt endre den komprimerte filen og redigere eierskapet til en fil? Jeg vet ikke om deg, men jeg kan ikke tenke på en måte.

Kan det være et verktøy bygget som, når alt er komprimert, endrer det den komprimerte filen og programmatisk redigerer eierskap og tillatelser ? Ja det kunne. Så enten kan du falske eierforholdene før du komprimerer, eller endre dem etter. Debian-folk bestemte at det første er lettere.

4. Hvorfor ikke bare bruke sudo?

Først og fremst trenger du ikke root-rettigheter for å bygge programvare, og du trenger ikke root-privilegier for å komprimere dem. Så hvis du ikke trenger det, må du virkelig være Windows-bruker for å tenke på å få den tillatelsen. Men sarkasme til side, du har kanskje ikke engang root-passord.

Dessuten, la oss si at du har root-tillatelser. Og la oss si at du vil late som at en fil bare skal ha lesetilgang til rot. Så du sudo, endrer faktisk fileieren og tillatelsene til root, du kommer ut av root shell og prøver å pakke alt. Du mislykkes fordi du nå ikke kan lese filen siden du ikke har root-tilgang. Så du må sudo og komprimere og bygge pakken som root. Effektivt må du gjøre alt som root.

Dette er dårlig ^TM .

Som pakker trenger du ikke rottillatelser, og du bør ikke få det. Når du installerer en pakke, kan det hende du må installere en fil (A) som root, og det er der du trenger root-tillatelser. Alt fakeroot gjør er å gjøre dette mulig. Den lar pakkelisten A som eies av root for arkiveren, slik at når pakken dekomprimeres av brukeren, krever arkiveren rottillatelse og oppretter A som eies av root.

Kommentarer

• Utmerket skriving, dette gjør det klart.
• So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier. Dette hjalp meg da jeg fortsatte å tenke ‘ hvorfor ikke endre det etter? ‘.
• Takk, dette rydder opp forvirringen jeg hadde etter å ha lest @Morten ‘ s svar

AFAIK, fakeroot kjører en kommando i et miljø der det ser ut til å ha rotprivilegier for filmanipulering. Dette er nyttig for å tillate brukere å opprette arkiver (tar, ar, .deb etc.) med filer i dem med rottillatelser / eierskap. Uten fakeroot ville man trenge å ha rotprivilegier for å opprette arkivens bestanddeler med riktig tillatelse og eierskap, og deretter pakke dem sammen, eller man måtte konstruere arkivene direkte uten å bruke arkiveren.

fakeroot fungerer ved å erstatte filmanipuleringsbiblioteksfunksjonene (chmod (), stat () osv.) med de som simulerer effekten virkelige biblioteksfunksjoner ville hatt, hadde brukeren virkelig vært rot.

Synopsis:

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

Sjekk mer her: fakeroot

Kommentarer

• @MaskTheSmokin: Så fakeroot gir deg superbrukerkraft bare for filmanipuleringsoperasjoner, ikke sant.
• Det gir egentlig ikke superbrukerkraft, den forfalsker det bare – programmet som kjører i det, tror det har rotprivilegier, mens det fortsatt bruker brukeren ‘ s normale privilegier.
• Hvor er forskjellen mellom the program running in it thinks it has root privileges og programmet som har root-rettigheter? Hvis jeg kan gjøre et rm -rf /, og programmet kjører, tror jeg at jeg har root-rettigheter …
• @userunknown. Du kan kanskje omgå rm ‘ s sjekker at du har tilstrekkelige tillatelser, men selve kjernen ville ikke ‘ ikke la deg gjøre det ; unlink systemanropet mislyktes. Det ‘ er ikke opp til applikasjonen alene for å håndtere tillatelser, eller du ‘ vil være i stand til å skrive din egen applikasjon som ikke ‘ t sjekk tillatelser og gjør hva du vil med det
• Et eksempel for å belyse behovet for fakeroot ville være fantastisk. Jeg kan se bruken av fakeroot, men jeg kan ikke ‘ ikke se hvorfor folk ikke kan ‘ ikke omgå rottillatelser til det punktet at det ‘ er lettere å forfalske det.

Jeg har brukt det til pakningsbyggingsskript. Jeg var ikke sikker på at personen som kjørte skript har tilgang til rotnivå, men skriptet trengte fremdeles å generere, for eksempel, en tar-fil som inneholdt filer som tilhører root. Den enkleste måten å gjøre det på var å kjøre skriptet for pakkebygging under fakeroot, som lurte arkiveren til å tro at filer tilhører root, og pakket dem inn slik i arkivet. På denne måten, da pakken ble pakket ut til destinasjonsmaskinen (helt på en annen maskin), tilhørte ikke filene rare eller ikke-eksisterende brukere.

Når jeg tenker på det, var det eneste stedet jeg har sett dette å bygge en slags arkiv: rootfs av innebygde systemer, tar.gz-arkiver, rpm-pakker, .deb-pakker osv.

Kommentarer

• fakeroot er et løsningsverktøy for bugged emballasjeprogramvare: det er ingen grunn til at du trenger å være root for å opprette slike pakker, b ut siden de ikke ‘ ikke lar deg spesifisere filtillatelser på annen måte enn å sette dem direkte i filsystemet før du ikke har noe valg

En vanlig bruk er å finne ut hvilke filer en mislykket binær virkelig ønsket å få tilgang til. Det vil si å finne ut og fikse eller jobbe med feil forårsaket av hardkodede baner og feil unntakshåndtering.

Du kan bruke fakeroot uten å ha root-rettigheter. Hvis du hadde su og / eller sudo, ville du kunne ødelegge systemet ditt med en enkel rm -rf /, men med fakeroot maksimalt vil du fjerne hjemmekatalogen.

Kommentarer

• Det betyr ikke ‘ t forklar behovet for fakeroot. Du kan fjerne hjemmekatalogen som deg selv.

Det enkle svaret:

su og sudo kjører kommandoer som root. fakeroot gjør ikke, utenfor det, en delvis sandkassearrangement.