Vad är behovet av `fakeroot`-kommando i linux

Tänk dig att du är en utvecklare / pakethållare, etc. som arbetar på en fjärrserver. Du vill uppdatera innehållet i ett paket och bygga om det, ladda ner och anpassa en kärna från kernel.org och bygga den osv. När du försöker göra dessa saker kommer du att upptäcka att vissa steg kräver att du har root rättigheter (UID och GID 0) av olika skäl (säkerhet, förbisedda behörigheter osv.). Men det är inte möjligt att få root rättigheter, eftersom du arbetar på en fjärrmaskin (och många andra användare har samma problem som du). Det här är exakt fakeroot gör: det låtsas som en effektiv UID och GID på 0 till den miljö som kräver dem.

I praktiken får du aldrig riktiga root privilegier (i motsats till su och sudo som du nämner).

Kommentarer

• så jag kan ’ t använda för att ändra systeminställningar ?? cuz kommandot vi ’ kommer att köra kommer att tro att det ’ körs som root och gör vad vi vill att det ska göra. vann ’ t it?
• @mrid Observera att ” I praktiken får du aldrig riktiga rootprivilegier ”. Så anwser är inget

För att tydligt se skillnaden mellan fakeroot och en riktig sudo / su, gör bara:

$ 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 är inom fakeroot-skalet ser det ut som om du är rot – så länge du inte försöker göra någonting som verkligen behöver rotprivilegier. Och det är precis vad ett förpackningsverktyg behöver för att göra paket som är meningsfulla på alla maskiner.

Faktum är att när du använder fakeroot för förpackning, vill du uppnå de verktyg du kör under fakeroot för att se dina filer ägs av root. Varken mer eller mindre. Så i själva verket fungerar su eller sudo inte för att få rätt filägande.

Kommentarer

• Är inte falskare farlig? Om jag skapar en fil med suidbiten och rx-perm skapas filen som ägs av root, körbar av vem som helst! Eller kanske det inte går att ställa in suidbiten?
• Inte bra. Jag testade detta själv. Den främsta anledningen till fakeroot är att få ägarrot: rot till inbyggda paket utan att vara root. installerade paket kommer dock att ha rätt tillstånd.
• Allt var väldigt förvirrande tills jag läste @ ntzrmtthihu777 ’ s kommentar!
• Tyvärr, Jag förstår inte ’ beskrivningen. Varför inte lappa verktygen så att de inte får ’ om du inte är root? Som en relaterad fråga: När allt kommer omkring ägs filerna som du skapar under fakeroot inte faktiskt av root. Skulle ’ inte detta innebära att när jag installerar en sådan .deb -fil, alla mina /usr filer ägs av den användare som heter fakeroot?
• @ JohannesSchaub-litb, nej det är ’ poängen. Filerna ägs inte av root, men i ett fakeroot -skal ser de ut som . När .deb-paketet skapas i detta skal läses filägaren från filsystemet (som fakeroot avlyssnar och returnerar root) och lagras i förpackningen. När paketet installeras kräver dpkg root-åtkomst eftersom paketet anger att filen ska ägas av root.

Eftersom svaren är svåra att förstå (för mig själv) och det tog en del tanke att förstå det ( denna kommentar fick mig att förstå det), jag ”m kommer att ge en förhoppningsvis bättre förklaring.

1. Vad händer i fakeroot

Inget mer än vad som händer med din egen användare. Absolut inget mer. Om du fakeroot (som när du anropar ger dig ett nytt skal, som sudo skulle), låtsas göra saker som du behövde tillstånd för och avsluta, absolut ingenting skulle hända.

Om du tänker på det är det totalt slöseri med tid. Varför skulle du göra saker som faktiskt inte händer? Det är galet. Du kunde helt enkelt inte ha gjort något av det och det hade inte varit någon skillnad, eftersom det inte finns något spår av det.

Vänta en stund …

2. Spåret av fakeroot

Det kan finnas ett spår kvar av fakeroot. Låt oss titta på kommandona i MortenSickels svar vilket är ganska trevligt och förtjänar en uppröstning:

$ 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 

Vid första anblicken ser det ut som att ha använt fakeroot var ett helt slöseri med tid. I slutändan, om du inte hade använt fakeroot, skulle du ha fått samma sak.

Den subtila saken här är den här:

$ cat root.tst Wow I have root access 

Vilket betyder att filens innehåll fortfarande kommer ihåg att det var en rot. Du kan säga att inte använda fakeroot skulle ha gett samma resultat. Du har rätt, det här exemplet är för enkelt.

Låt oss ta ett annat exempel:

$ 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 

Låt oss se vad som hände. Jag låtsades vara root, vilket är helt ineffektivt, och skapade x och y. Jag låtsades att x tillhörde myuser och y tillhörde root. De tillhör faktiskt båda myuser (som vi kan se i slutändan), men jag lät bara det vara så.

Sedan skapade jag en lista och sparade min fantasi i en fil. Senare när jag tittar tillbaka på filen kan jag se vem jag trodde att filerna skulle ägas av. Återigen ägs de faktiskt inte av människor jag föreställde mig, jag föreställde mig bara det.

3. Så … Varför vill du ha det igen?

Du kan säga att jag inte verkligen behövde vara falsk för att skapa den listan. Jag kunde helt enkelt ha skapat listan och sedan redigerat den för att spegla min fantasi. Du har rätt, du behövde inte fakeroot för det. Att veta att fakeroot faktiskt inte gör någonting, kan faktiskt inte ha fått någon förmåga som du inte hade tidigare.

Men , och det är vad fakeroot handlar om, redigering av listan kan vara otrevlig.Som med ett paket som kan installeras på ditt system har du en tar ed, gzip ed, xz ed, bzip2 ed eller något annat format som håller dina filer tillsammans och kommer ihåg deras behörigheter och ägare. Kan du enkelt ändra den komprimerade filen och redigera äganderätten till en fil? Jag vet inte om dig, men jag kan inte tänka mig ett sätt.

Kan det finnas ett verktyg byggt som, när allt är komprimerat, ändrar det den komprimerade filen och programmatiskt redigerar äganderätten och behörigheterna ? Ja det kunde. Så antingen kan du förfalska ägarskapen innan du komprimerar eller ändra dem efter. Debians folk bestämde att det förra är lättare.

4. Varför inte bara använda sudo?

Först och främst behöver du inte root-privilegier för att bygga programvara och du behöver inte root-privilegier för att komprimera dem. Så om du inte behöver det, måste du verkligen vara Windows-användare för att ens tänka på att få det tillståndet. Men sarkasm åt sidan, kanske du inte ens har root-lösenord.

Dessutom, låt oss säga att du har rootbehörigheter. Och låt oss säga att du vill låtsas att en fil bara ska ha läsbehörighet till rot. Så du sudo, ändrar faktiskt filägaren och behörigheterna till root, du kommer ur rotskalet och försöker paketera allt. Du misslyckas eftersom du nu inte kan läsa filen längre eftersom du inte har rootåtkomst. Så du måste sudo och komprimera och bygga paketet som root. Effektivt måste du göra allt som root.

Detta är dåligt ^TM .

Som förpackare behöver du inte rootbehörigheter och du borde inte få det. När du installerar ett paket kan du behöva installera någon fil (A) som root och det är där du behöver rootbehörigheter. Allt som fakeroot gör är att göra detta möjligt. Det låter förpackarlistan A som ägs av root för arkiveraren, så att när paketet dekomprimeras av användaren, kräver arkiveraren rootbehörighet och skapar A som ägs av root.

Kommentarer

• Utmärkt skrivning, det gör det tydligt.
• So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier. Detta hjälpte mig när jag hela tiden tänkte ’ varför inte ändra det efter? ’.
• Tack, det här rensar förvirringen jag hade efter att ha läst @Morten ’ s svar

AFAIK, fakeroot kör ett kommando i en miljö där det verkar ha rootprivilegier för filmanipulation. Detta är användbart för att tillåta användare att skapa arkiv (tar, ar, .deb etc.) med filer i dem med rootbehörigheter / äganderätt. Utan fakeroot skulle man behöva ha root-privilegier för att skapa arkivens beståndsdelar med rätt behörighet och ägande, och sedan packa upp dem, eller så skulle man behöva konstruera arkiven direkt utan att använda arkiveraren.

fakeroot fungerar genom att ersätta filmanipuleringsbiblioteksfunktionerna (chmod (), stat () etc.) med sådana som simulerar den effekt de verkliga biblioteksfunktionerna skulle ha haft om användaren verkligen hade rotat.

Synopsis:

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

Kolla mer här: fakeroot

Kommentarer

• @MaskTheSmokin: Så fakeroot ger dig superanvändarkraft bara för filhantering, eller hur.
• Det ger inte riktigt superanvändarkraft, den förfalskar den bara – programmet som körs i den tycker att det har root-privilegier, medan det verkligen fortfarande använder användaren ’ s normala privilegier.
• Var är skillnaden mellan the program running in it thinks it has root privileges och programmet som har rootprivilegier? Om jag kan göra ett rm -rf / och programmet, kör det, tror jag att jag har rootprivilegier …
• @userunknown Du kanske kan kringgå rm ’ s kontrollerar att du har tillräckliga behörigheter, men själva kärnan skulle inte ’ inte låta dig göra det ; unlink systemanropet misslyckades. Det ’ är inte upp till applikationen ensam för att hantera behörigheter, eller så kan du ’ skriva din egen applikation som inte ’ t kolla behörigheterna och gör vad du vill med det
• Ett exempel för att klargöra behovet av fakeroot skulle vara fantastiskt. Jag kan se användningen av fakeroot, men jag ’ t ser varför människor inte kan ’ t kringgå root-behörigheter till den punkt att det ’ är lättare att fejka det.

Jag har använt det för paketbyggnadsskript. Jag var inte säker på att personen som kör skript har tillgång till rotnivå, men skriptet behövde fortfarande generera, säg, en tar-fil som innehöll filer som tillhör root. Det enklaste sättet att göra det var att köra paketbyggnadsskriptet under fakeroot, vilket lurade arkiveraren att tro att filer tillhör root och packade upp dem som sådana i arkivet. På detta sätt, när paketet packades upp till destinationsmaskinen (helt på en annan maskin), tillhörde filerna inte konstiga eller icke-existerande användare.

Att tänka på det, det enda stället jag har sett detta var för att bygga något slags arkiv: rootfs av inbäddade system, tar.gz arkiv, rpm-paket, .deb-paket, etc.

Kommentarer

• fakeroot är ett lösningsverktyg för bugged förpackningsprogramvara: det finns ingen anledning att du behöver vara root för att skapa sådana paket, b ut eftersom de inte ’ inte tillåter dig att ange filbehörigheter på något annat sätt än att ställa in dem direkt i filsystemet innan du har inget val

En vanlig användning är att ta reda på vilka filer en falsk binär verkligen ville komma åt. Det vill säga att ta reda på eller åtgärda buggar orsakade av hårda kodade banor och felaktig undantagshantering.

Du kan använd fakeroot utan att ha root-behörigheter. Om du hade su och / eller sudo skulle du kunna förstöra ditt system med en enkel rm -rf /, men med högst fakeroot skulle du ta bort din hemkatalog.

Kommentarer

• Det är inte ’ t förklara behovet av fakeroot. Du kan ta bort din hemkatalog som dig själv.

Det enkla svaret:

su och sudo kör kommandon som root. fakeroot gör inte, utanför dess partiella sandlådearrangemang.