Proč vůbec potřebujeme příkaz fakeroot
? Nemůžeme jednoduše použít příkazy Sudo
nebo su
?
Manová stránka říká:
fakeroot - spouští příkaz v prostředí předstírající rootová oprávnění pro manipulace se soubory
About.com říká:
Poskytuje falešné kořenové prostředí. Účelem tohoto balíčku je povolit něco jako:
dpkg-buildpackage -rfakeroot
tj. odstranit potřebu stát se rootem pro sestavení balíčku. To se provádí nastavenímLD_PRELOAD
tolibfakeroot.so
, který poskytuje obálky kolemgetuid
,chown
,chmod
,mknod
,stat
, ..., čímž vytváří falešný kořenové prostředí. Pokud tomu nerozumíte, nepotřebujetefakeroot
!
Moje otázka zní, jaký zvláštní účel to řeší, že jednoduchý su
nebo Sudo
ne? Například pro přebalení všech nainstalovaných balíčků v ubuntu dáváme následující příkaz:
$ fakeroot -u dpkg-repack `dpkg --get-selections | grep install | cut -f1`
Můžeme udělat výše uvedený příkaz se Sudo nebo su místo fakeroot takto:
$ Sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`
ÚPRAVA:
Běh:
$ Sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`
dává mi tuto chybu:
kontrolní adresář má špatná oprávnění 700 (musí být> = 0755 a <= 0775)
Z jakého důvodu?
Představte si, že jste vývojář/správce balíků atd. Pracující na vzdáleném serveru. Chcete aktualizovat obsah balíčku a znovu jej sestavit, stáhnout a přizpůsobit jádro z kernel.org a vytvořit jej, atd. Při pokusu o tyto věci zjistíte, že některé kroky vyžadují, abyste měli root
práva (UID
a GID
0) z různých důvodů (zabezpečení, přehlížená oprávnění atd.). Není však možné získat práva root
, protože pracujete na vzdáleném počítači (a mnoho dalších uživatelů má stejný problém jako vy). Přesně toto dělá fakeroot
: předstírá efektivní UID
a GID
z 0 do prostředí, které je vyžaduje.
V praxi nikdy nedostanete skutečná root
oprávnění (na rozdíl od su
a Sudo
, které zmiňujete).
Chcete-li jasně vidět rozdíl mezi fakerootem a skutečným sudo/su, stačí:
$ 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
Dokud jste v prostředí fakeroot Shell, vypadá to, že jste root - pokud se nepokoušíte dělat nic, co by opravdu vyžadovalo rootová privilegia. A to je přesně to, co potřebuje balicí nástroj k výrobě balíků, které budou mít smysl na jakémkoli stroji.
Ve skutečnosti, když pro balení používáte fakeroot, chcete dosáhnout toho, aby nástroje, které běží pod fakerootem, viděly vaše soubory jako root. Nic víc nic míň. Ve skutečnosti tedy su nebo Sudo nebude fungovat pro získání správného vlastnictví souboru.
Vzhledem k tomu, že odpovědi jsou těžko pochopitelné (pro sebe) a trvalo to nějaké přemýšlení, než to pochopit ( tento komentář mě přiměl pochopit to), chystám se dát snad lepší vysvětlení.
Nic víc, než co se stane s vaším vlastním uživatelem. Rozhodně nic víc. Pokud jste fakeroot
(což vám při zavolání dává nový Shell, jako by to udělal Sudo
), předstírejte, že budete dělat věci, pro které potřebujete povolení, a ukončete, absolutně by se nic nestalo.
Pokud o tom přemýšlíte, je to naprostá ztráta času. Proč byste dělali věci, které se ve skutečnosti nestanou? Je to šílené. Dalo by se jednoduše nic z toho udělat a nebyl by žádný rozdíl, protože neexistuje žádná stopa.
Počkej chvíli...
Tam by mohlo být stopy po fakeroot
. Podívejme se na příkazy v odpověď MortenSickel , což je pěkně pěkné a zaslouží si hlasování:
$ 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
Na první pohled to vypadá, že použití fakeroot
bylo naprostou ztrátou času. Nakonec, kdybyste nepoužívali fakeroot
, dostali byste totéž.
Tahle věc je tato:
$ cat root.tst
Wow I have root access
Což znamená, že obsah souboru si stále pamatuje, že je root. Dalo by se říci, že nepoužívání fakeroot
by přineslo stejné výsledky. Máte pravdu, tento příklad je příliš jednoduchý.
Vezměme si další příklad:
$ 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
Uvidíme, co se stane. Předstíral jsem, že jsem root
, což je naprosto neúčinné, a vytvořil jsem x
a y
. Předstíral jsem, že x
patří do myuser
a y
patří do root
. Vlastně oba patří do myuser
(jak můžeme vidět na konci), ale já jen předstíral , že to tak je.
Poté jsem vytvořil seznam a uložil jsem svou fantazii do souboru. Později, když se podívám zpět na soubor, vidím, komu jsem si představoval, že soubory by měly být ve vlastnictví. Opět, ve skutečnosti nejsou ve vlastnictví lidí, které jsem si představoval, prostě jsem si to jen představoval.
Můžete říci, že jsem opravdu nemusel předstírat, že jsem vytvořil tento root. Mohl jsem jednoduše vytvořit seznam a poté jej upravit tak, aby odrážel mou představivost. Máte pravdu, nepotřebovali jste na to fakeroot
. Ve skutečnosti s vědomím, že fakeroot
ve skutečnosti nic nedělá, nemůžete získat žádnou schopnost, kterou jste předtím neměli.
Ale , a to je to, o čem fakeroot
může být úprava seznamu netriviální. Stejně jako u balíčku, který lze nainstalovat do vašeho systému, máte tar
ed, gzip
ed, xz
ed, bzip2
ed nebo jakýkoli jiný formát, který udržuje vaše soubory pohromadě a pamatuje si svá oprávnění a vlastníky. Můžete snadno upravit komprimovaný soubor a upravit vlastnictví souboru? Nevím o vás, ale nedokážu vymyslet nějaký způsob.
Mohl by být vytvořen nástroj, který, jakmile bude vše komprimováno, upraví komprimovaný soubor a programově upraví vlastnická práva a oprávnění? Ano, mohl. Takže můžete buď předstírat vlastní vlastnictví, nebo je změnit. Lidé v Debianu rozhodli, že první je jednodušší.
Sudo
?Nejprve nepotřebujete oprávnění root pro vytváření softwaru a ke komprimaci nepotřebujete oprávnění root. Takže pokud to nepotřebujete, musíte být opravdu uživatelem Windows, abyste si na toto povolení mysleli. Ale sarkasmus stranou nemusíte mít ani root heslo.
Kromě toho řekněme, že máte oprávnění root. A řekněme, že chcete předstírat, že soubor by měl mít přístup ke čtení pouze do kořenového adresáře. Takže Sudo
, vlastně změníte vlastníka souboru a oprávnění na root
, dostanete se z kořenového prostředí Shell a pokuste se vše zabalit. Zlyháte, protože nyní již nemůžete číst soubor, protože nemáte přístup root. Takže musíte Sudo
a komprimovat a sestavit balíček jako root. Efektivně musíte dělat vše jako root.
Je to špatnéTM.
Jako balič nepotřebujete oprávnění root a neměli byste je získat. Když instalujete balíček, možná budete muset nainstalovat nějaký soubor (A
) jako root a tam budete potřebovat oprávnění root. Vše, co dělá fakeroot
, je umožnit. Umožňuje archivnímu seznamu A
, jak je ve vlastnictví root, pro archivátora, takže když uživatel balík dekomprimuje, vyžaduje oprávnění root a vytvoří A
jako root.
AFAIK, fakeroot spustí příkaz v prostředí, ve kterém se zdá, že má oprávnění uživatele root pro manipulaci se soubory. To je užitečné pro umožnění uživatelům vytvářet archivy (dehty, ar, .deb atd.) Se soubory v nich s oprávněním root/vlastnictvím. Bez fakeroot by bylo třeba mít rootová oprávnění, aby bylo možné vytvořit základní soubory archivů se správnými oprávněními a vlastnictvím, a pak je zabalit, nebo by bylo nutné archivy sestavit přímo, bez použití archivátoru.
fakeroot funguje tak, že nahradí funkce knihovny pro manipulaci se soubory (chmod (), stat () atd.) těmi, které simulují účinek, jaký by skutečné funkce knihovny měly, pokud by byl uživatel skutečně root.
Synopse:
fakeroot [-l|--lib library] [--faked faked-binary] [--] [command]
Více zde: fakeroot
Použil jsem to pro skripty pro vytváření balíčků. Nebyl jsem si jistý, zda osoba provozující skript má přístup na úrovni root, ale skript stále potřeboval vygenerovat, řekněme, soubor dehtu, který obsahoval soubory, které patří kořenovému adresáři. Nejjednodušší způsob, jak to provést, byl spustit skript pro vytváření balíčků pod fakerootem, který archivátora přiměl k tomu, aby věřil, že soubory patří do kořenového adresáře, a zabalil je jako takový do archivu. Tímto způsobem, když byl balíček rozbalen do cílového počítače (celkem na jiném počítači), soubory nepatřily podivným nebo neexistujícím uživatelům.
Když jsem o tom přemýšlel, jediné místo, které jsem viděl, bylo vytvoření nějakého archivu: rootfy vestavěných systémů, archivy tar.gz, rpm balíčky, .deb balíčky atd.
Jedním z běžných způsobů použití je zjistit, ke kterým souborům by selhal binární soubor skutečně chtěl získat přístup. To znamená, zjišťovat a opravovat nebo řešit chyby způsobené pevně kódovanými cestami a nesprávným zpracováním výjimek.
Jednoduchá odpověď:
su a Sudo spouští příkazy jako root. fakeroot ne, mimo její částečné uspořádání karantény.
Můžete použít fakeroot, aniž byste ve skutečnosti měli oprávnění root. Pokud byste měli su
a/nebo Sudo
, mohli byste zničit svůj systém jednoduchým rm -rf /
, ale s maximálně fakerootem byste odstranili svůj domovský adresář.