Hvad er behovet for kommandoen `fakeroot` i linux

Forestil dig at du er en udvikler / pakkeholder osv., der arbejder på en ekstern server. Du vil opdatere indholdet af en pakke og genopbygge den, downloade og tilpasse en kerne fra kernel.org og opbygge den osv. Mens du prøver at gøre disse ting, vil du finde ud af, at nogle trin kræver, at du har root rettigheder (UID og GID 0) af forskellige årsager (sikkerhed, oversete tilladelser osv.). Men det er ikke muligt at få root rettigheder, da du arbejder på en ekstern maskine (og mange andre brugere har det samme problem som dig). Dette er præcis fakeroot gør: det foregiver en effektiv UID og GID på 0 til det miljø, der kræver dem.

I praksis får du aldrig ægte root privilegier (modsat su og sudo som du nævner).

Kommentarer

• så jeg kan ‘ t bruge for at ændre systemindstillinger ?? cuz kommandoen, som vi ‘ vil køre, vil tro, at den ‘ kører som root og gør hvad vi vil have det. vandt ‘ t det?
• @mrid Bemærk ” I praksis får du aldrig rigtige rodprivilegier “. Så anwser er nej

For tydeligt at se forskellen mellem fakeroot og en reel sudo / su, bare gø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å længe du er inden for fakeroot-skallen, ser det ud som om du er rod – så længe du ikke prøver at gøre noget der virkelig har brug for rodprivilegier. Og det er præcis, hvad et emballeringsværktøj har brug for til at fremstille pakker, der giver mening på enhver maskine.

Når du bruger fakeroot til emballering, skal du faktisk gøre de værktøjer, du kører under fakeroot, for at se dine filer ejes af root. Intet mere, intet mindre. Så i virkeligheden fungerer su eller sudo ikke til at få det rigtige filejerskab.

Kommentarer

• Er ikke falsker farlig? Hvis jeg opretter en fil med suid-bit og rx-perm, oprettes filen ejet af root, eksekverbar af enhver, som root! Eller måske fungerer indstilling af suid-bit ikke?
• Ikke godt. Jeg prøvede det selv. Den primære årsag til fakeroot er at få ejerskabsrod: rod i indbyggede pakker uden faktisk at være rod. installerede pakker har dog ordentlige tilladelser.
• Det hele var meget forvirrende, indtil jeg læste @ ntzrmtthihu777 ‘ s kommentar!
• Undskyld, Jeg forstår ‘ ikke beskrivelsen. Hvorfor lappe ikke værktøjerne, så de ikke vinder ‘, hvis du ikke er rod? Som et relateret spørgsmål: Når alt kommer til alt er de filer, du opretter under fakeroot, ikke faktisk ejet af root. Ville ‘ ikke dette antyde, at når jeg installerer en sådan .deb -fil, skal alle mine /usr filer ejes af den bruger, der hedder fakeroot?
• @ JohannesSchaub-litb, nej det er ‘. Filerne ejes ikke af root, men inde i en fakeroot shell, ser de ud som de er. Når .deb-pakken oprettes inde i denne skal, læses filejeren fra filsystemet (som fakeroot opfanger og returnerer root) og opbevares i pakken. Når du installerer pakken, kræver dpkg derefter rootadgang, fordi pakken angiver, at filen skal ejes af root.

Da svarene er svære at forstå (for mig selv), og det krævede en del tænkning at forstå det ( denne kommentar fik mig til at forstå det), jeg “m vil give en forhåbentlig bedre forklaring.

1. Hvad sker der i fakeroot

Intet mere end hvad der sker med din egen bruger. Absolut intet mere. Hvis du fakeroot (som når det kaldes giver dig en ny skal, som sudo ville), foregiver at gøre ting, som du havde brug for tilladelse til, og afslutte, der ville intet ske.

Hvis du tænker over det, er det et totalt spild af tid. Hvorfor ville du lave ting, der ikke rent faktisk sker? Det er sindssygt. Du kunne simpelthen ikke have gjort noget af det, og der ville ikke have været nogen forskel, da der ikke er noget spor af det.

Vent et øjeblik …

2. Sporet af fakeroot

Der kunne være et spor tilbage af fakeroot. Lad os se på kommandoerne i MortenSickels svar , der er ret pænt og fortjener en opstemning:

$ 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 øjekast ser det ud som at have brugt fakeroot var totalt spild af tid. I sidste ende, hvis du ikke havde brugt fakeroot, ville du have fået det samme ting.

Den subtile ting her er dette:

$ cat root.tst Wow I have root access 

Hvilket betyder, at filens indhold stadig husker at være en rod. Du kan sige, at ikke at bruge fakeroot ville have givet de samme resultater. Du har ret, dette eksempel er for simpelt.

Lad os tage et andet 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 

Lad os se, hvad der skete. Jeg foregav at være root, hvilket er totalt ineffektivt, og skabte x og y. Jeg foregav at x tilhørte myuser og y at tilhøre root. De hører faktisk begge til myuser (som vi kan se i sidste ende), men jeg lod bare lade det være sådan.

Så oprettede jeg en liste og gemte min fantasi i en fil. Senere når jeg ser tilbage på filen, kan jeg se, hvem jeg forestillede mig, at filerne skulle ejes af. Igen ejes de faktisk ikke af mennesker, jeg forestillede mig, det forestillede jeg mig bare.

3. Så … Hvorfor vil du have det igen?

Du siger måske, at jeg ikke virkelig havde brug for at falske at være root for at oprette denne liste. Jeg kunne simpelthen have oprettet listen og derefter redigeret den for at afspejle min fantasi. Du har ret, du behøvede ikke fakeroot til det. Faktisk ved du at vide, at fakeroot ikke gør noget, kan du muligvis have opnået enhver evne, du ikke havde før.

Men , og det er hvad fakeroot handler om, redigering af listen kan være ikke-privat.Som det er med en pakke, der kan installeres på dit system, har du en tar ed, gzip ed, xz ed, bzip2 ed eller ethvert andet format, der holder dine filer sammen og husker deres tilladelser og ejere. Kan du let ændre den komprimerede fil og redigere ejerskabet af en fil? Jeg ved ikke noget om dig, men jeg kan ikke tænke på en måde.

Kunne der være et værktøj, der, når alt er komprimeret, ændrer det den komprimerede fil og programmatisk redigerer ejerskab og tilladelser ? Ja der kunne. Så enten kunne du falske ejerforholdene inden komprimering eller ændre dem efter. Debian-folk besluttede, at førstnævnte er lettere.

4. Hvorfor ikke bare bruge sudo?

Først og fremmest behøver du ikke root-rettigheder til at opbygge software, og du behøver ikke root-privilegier for at komprimere dem. Så hvis du ikke har brug for det, skal du virkelig være en Windows-bruger for selv at tænke på at få den tilladelse. Men sarkasme til side, du har muligvis ikke engang rodadgangskode.

Desuden lad os sige, at du har rodtilladelser. Og lad os sige, at du vil lade som om, at en fil kun skal have læseadgang til rod. Så du sudo, ændrer faktisk filens ejer og tilladelser til root, du kommer ud af rodskallen og prøver at pakke alt. Du mislykkes, fordi du nu ikke kan læse filen længere, da du ikke har rodadgang. Så du skal sudo og komprimere og bygge pakken som rod. Effektivt skal du gøre alt som root.

Dette er dårligt ^TM .

Som pakker behøver du ikke rodtilladelser, og du skal ikke få det. Når du installerer en pakke, skal du muligvis installere en fil (A) som root, og det er der, hvor du har brug for root-tilladelser. Alt, hvad fakeroot gør, er at gøre dette muligt. Det lader pakkelisten A som ejet af root til arkiveren, så når pakken dekomprimeres af brugeren, kræver arkiveren rodtilladelse og opretter A som ejet af root.

Kommentarer

• Fremragende skrivning, det gø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 mig, da jeg ved med at tænke ‘ hvorfor ikke ændre det efter? ‘.
• Tak, dette rydder op i den forvirring, jeg havde efter at have læst @Morten ‘ s svar

AFAIK, fakeroot kører en kommando i et miljø, hvor det ser ud til at have rodprivilegier til filmanipulation. Dette er nyttigt for at tillade brugere at oprette arkiver (tar, ar, .deb osv.) Med filer i dem med rodtilladelser / ejerskab. Uden fakeroot ville man være nødt til at have rodrettigheder til at oprette arkiverne med de korrekte tilladelser og ejerskab og derefter pakke dem sammen, ellers ville man skulle konstruere arkiverne direkte uden at bruge arkiveren.

fakeroot fungerer ved at erstatte filmanipulationsbiblioteksfunktionerne (chmod (), stat () osv.) med dem, der simulerer den virkning, som de virkelige biblioteksfunktioner ville have haft, hvis brugeren virkelig havde været root.

Synopsis:

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

Se mere her: fakeroot

Kommentarer

• @MaskTheSmokin: Så fakeroot giver dig kun superbrugerkraft til filmanipuleringshandlinger, ikke sandt.
• Det giver ikke rigtig superbrugerkraft, det forfalsker det kun – programmet, der kører i det, mener, at det har rodrettigheder, mens det stadig stadig bruger brugerens ‘ s normale privilegier.
• Hvor er forskellen mellem the program running in it thinks it has root privileges og programmet, der har rodrettigheder? Hvis jeg kan udføre et rm -rf /, og programmet kører det, tror jeg, at jeg har rodrettigheder …
• @userunknown. Du kan muligvis omgå rm ‘ s kontrollerer, at du har tilstrækkelige tilladelser, men selve kernen ville ikke ‘ ikke lade dig gøre det ; unlink systemopkald mislykkedes. Det ‘ er ikke op til applikationen alene til at håndtere tilladelser, eller du ‘ kunne skrive din egen applikation, der ikke ‘ t kontroller tilladelser og gør hvad du vil med det
• Et eksempel på at belyse behovet for fakeroot ville være fantastisk. Jeg kan se brugen af fakeroot, men jeg kan ikke ‘ ikke se, hvorfor folk ikke kan ‘ t arbejde rundt om rodtilladelser til det punkt, at det ‘ er lettere at falske det.

Jeg har brugt det til pakkebygningsscript. Jeg var ikke sikker på, at den person, der kører script har adgang til rodniveau, men scriptet var stadig nødvendigt for at generere f.eks. en tar-fil, der indeholdt filer, der hører til root. Den enkleste måde at gøre det på var at køre pakkebygningsscriptet under fakeroot, hvilket narrede arkiveren til at tro, filer tilhører root og pakket dem som sådan inde i arkivet. På denne måde, da pakken blev pakket ud til destinationsmaskinen (helt på en anden maskine), tilhørte filerne ikke underlige eller ikke-eksisterende brugere.

Når jeg tænker på det, var det eneste sted, jeg har set dette, at bygge en slags arkiv: rootfs af indlejrede systemer, tar.gz arkiver, rpm-pakker, .deb-pakker osv.

Kommentarer

• fakeroot er et løsningsværktøj til bugged emballagesoftware: der er ingen grund til, at du skal være rod for at oprette sådanne pakker, b ut da de ikke ‘ ikke tillader dig at specificere filtilladelser på anden måde end at indstille dem direkte i filsystemet før du ikke har noget valg

En almindelig anvendelse er at finde ud af, hvilke filer en svigtende binær virkelig ønskede at få adgang til. Det vil sige at finde ud af og rette eller arbejde med fejl forårsaget af hårdt kodede stier og forkert håndtering af undtagelser.

Du kan brug fakeroot uden faktisk at have rodrettigheder. Hvis du havde su og / eller sudo, ville du være i stand til at ødelægge dit system med et simpelt rm -rf /, men højst med fakeroot fjerner du din hjemmekatalog.

Kommentarer

• Det er ikke ‘ t forklarer behovet for fakeroot. Du kan fjerne din hjemmemappe som dig selv.

Det enkle svar:

su og sudo køre kommandoer som root. fakeroot gør ikke uden for det delvise sandkassearrangement.