Jaka jest potrzeba polecenia „fakeroot” w systemie Linux


92

Dlaczego w ogóle potrzebujemy fakerootdowodzenia? Czy nie możemy po prostu użyć poleceń sudolub su?

Strona podręcznika mówi:

fakeroot - uruchom w środowisku fałszywe uprawnienia roota do manipulowania plikami

About.com mówi:

Daje fałszywe środowisko root. Ten pakiet ma na celu włączenie czegoś takiego: dpkg-buildpackage -rfakerootnp. Usunięcie potrzeby rootowania dla kompilacji pakietu. Odbywa się to poprzez ustawienie LD_PRELOADsię libfakeroot.so, która zapewnia otoki wokół getuid, chown, chmod, mknod, stat, ..., tworząc w ten sposób fałszywy środowiska korzeniowego. Jeśli nic nie rozumiesz, nie potrzebujesz fakeroot!

Moje pytanie brzmi: jaki specjalny cel rozwiązuje to proste, suczy sudonie? Na przykład w celu przepakowania wszystkich zainstalowanych pakietów w Ubuntu wydajemy następujące polecenie:

$ fakeroot -u dpkg-repack `dpkg --get-selections | grep install | cut -f1`

Czy możemy wykonać powyższe polecenie za pomocą sudo lub su zamiast fakeroot w następujący sposób:

$ sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`

EDYTOWAĆ:

Bieganie:

$ sudo dpkg-repack `dpkg --get-selections | grep install | cut -f1`

daje mi ten błąd:

katalog sterujący ma złe uprawnienia 700 (musi być> = 0755 i <= 0775)

Jakiś powód dlaczego?


6
ze względów bezpieczeństwa dobrym pomysłem jest unikanie wykonywania jako root wszystkiego, co można zrobić jako zwykły użytkownik, nawet jeśli możesz uruchomić sudolub suponieważ jest to twój komputer. fakerootma dwa zastosowania 1) oszuka programy, które uważają, że rzeczywiście jesteś użytkownikiem root, czego może wymagać niektóre źle napisane oprogramowanie prawnie zastrzeżone, nawet jeśli nie jest potrzebne (zwykle deweloper Windows nie ma Linuksa) oraz 2) pozwala na emulację zmian trybu plików i własności, których nie w przeciwnym razie można to zrobić, głównie w celu utworzenia tarpliku z prawidłowymi uprawnieniami i prawem własności, przydatnego na przykład podczas pakowania oprogramowania.
pqnet,

1
Myślę, że notatka we fragmencie About.com podsumowuje: Jeśli czegoś nie rozumiesz, nie potrzebujesz fakeroot! Jeśli nie możesz wymyślić sytuacji, w której fakerootjest to przydatne, to dosłownie nie potrzebujesz go. Ale ludzie, którzy faktycznie tego potrzebują, całkowicie rozumieją przypadek użycia.
Christopher Schultz,

Odpowiedzi:


68

Wyobraź sobie, że jesteś programistą / opiekunem pakietów itp. Pracującym na zdalnym serwerze. Chcesz zaktualizować zawartość pakietu i odbudować go, pobrać i dostosować jądro z kernel.org i zbudować go itp. Próbując to zrobić, przekonasz się, że niektóre kroki wymagają posiadania rootuprawnień ( UIDi GID0) z różnych powodów (bezpieczeństwo, przeoczone uprawnienia itp.). Nie można jednak uzyskać rootuprawnień, ponieważ pracujesz na zdalnym komputerze (a wielu innych użytkowników ma taki sam problem jak Ty). Właśnie to fakerootrobi: udaje, że jest skuteczny UIDi równy GID0 środowisku, które tego wymaga.

W praktyce nie można uzyskać rzeczywiste rootprzywileje (w przeciwieństwie do sui sudoże wspominając).


więc nie mogę fakerootzmienić ustawień systemowych? bo polecenie, które będziemy wykonywać, będzie myślało, że działa jako root i robi wszystko, co chcemy. prawda?
mrid

3
@mrid Uwaga: „W praktyce nigdy nie dostajesz prawdziwych uprawnień roota”. Więc odpowiedź nie jest
sakisk

52

Aby wyraźnie zobaczyć różnicę między fakeroot a prawdziwym sudo / su, po prostu wykonaj:

$ 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

Tak długo, jak jesteś w powłoce fakeroot, wygląda na to, że jesteś rootem - o ile nie próbujesz robić niczego, co naprawdę wymaga uprawnień roota. I właśnie tego potrzebuje narzędzie do tworzenia opakowań, które będzie miało sens na każdej maszynie.

W rzeczywistości, gdy używasz fakeroot do pakowania, to chcesz, aby narzędzia działające pod fakeroot były widoczne dla twoich plików jako root. Nic dodać nic ująć. Tak więc w rzeczywistości su lub sudo nie będą działać, aby uzyskać odpowiednią własność pliku.


Czy oszust nie jest niebezpieczny? Jeśli utworzę plik z bitem suid i uprawnieniem rx, plik zostanie utworzony jako własność root, wykonywalny przez każdego, jako root! A może ustawienie bitu suid nie zadziała?
Frizlab

7
Nie dobrze. Sam tego spróbowałem. Podstawowym powodem fakeroot jest zdobycie własności root: root w wbudowanych pakietach bez faktycznego rootowania. zainstalowane pakiety będą miały jednak odpowiednie perms.
hanetzer

2
Wszystko było bardzo mylące, dopóki nie przeczytałem komentarza @ ntzrmtthihu777!
Shahbaz

Przepraszam, nie rozumiem opisu. Dlaczego nie załatać narzędzi, aby nie narzekały, jeśli nie jesteś rootem? Jako powiązane pytanie: W końcu pliki tworzone przez fakeroot nie są faktycznie własnością root. Czy nie oznacza to, że kiedy instaluję taki .debplik, wszystkie moje /usrpliki są własnością każdego, kto zadzwonił fakeroot?
Johannes Schaub - litb

@ JohannesSchaub-litb, nie o to chodzi. Pliki nie są własnością root, ale wewnątrz fakerootpowłoki wyglądają tak , jak są. Gdy pakiet .deb jest tworzony w tej powłoce, właściciel pliku jest odczytywany z systemu plików (który fakerootprzechwytuje i zwraca root) i jest przechowywany w pakiecie. Podczas instalowania pakietu dpkg wymaga dostępu do konta root, ponieważ pakiet wskazuje, że plik powinien być własnością root.
Shahbaz

45

Ponieważ odpowiedzi są trudne do zrozumienia (dla siebie) i zastanowienie się nad tym zajęło trochę czasu ( ten komentarz sprawił, że zrozumiałem), mam nadzieję, że wyjaśnię to lepiej.

1. Co dzieje się w Fakeroot

Nic więcej niż to, co dzieje się z własnym użytkownikiem. Absolutnie nic więcej. Jeśli ty fakeroot(który po wywołaniu daje ci nową powłokę, tak jak sudozrobiłbyś), udajesz, że robisz rzeczy, na które potrzebujesz pozwolenia, i wychodzisz, absolutnie nic by się nie wydarzyło.

Jeśli się nad tym zastanowić, to całkowita strata czasu. Dlaczego miałbyś robić rzeczy, które tak naprawdę by się nie wydarzyły? To niesamowite. Mógłbyś po prostu tego nie zrobić i nie byłoby różnicy, ponieważ nie ma na to śladu.

Poczekaj minutę...

2. Ślad fakeroot

Nie mogło być śladu lewej fakeroot. Spójrzmy na polecenia w odpowiedzi MortenSickel, która jest całkiem ładna i zasługuje na głosowanie:

$ 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 pierwszy rzut oka wygląda na to, że korzystanie z niego fakerootbyło całkowitą stratą czasu. W końcu, gdybyś nie używał fakeroot, miałbyś to samo.

Subtelna rzecz jest tutaj:

$ cat root.tst
Wow I have root access

Co oznacza, że ​​zawartość pliku nadal pamięta, że ​​jest rootem. Można powiedzieć, że nieużywanie fakerootprzyniosłoby takie same wyniki. Masz rację, ten przykład jest zbyt prosty.

Weźmy inny przykład:

$ 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

Zobaczmy co się stało. Udawałem, że jestem root, co jest całkowicie nieskuteczne, i stworzyłem xi y. Udawałem, xże należę myuseri ynależę root. Oba należą do myuser(jak widzimy na końcu), ale udawałem, że tak właśnie jest.

Następnie stworzyłem listę i zapisałem moją wyobraźnię w pliku. Później, gdy patrzę wstecz na plik, widzę, kto według mnie powinien być właścicielem plików. Znów nie są własnością ludzi, których sobie wyobrażałem, po prostu sobie to wyobraziłem.

3. Więc ... Dlaczego tego chcesz ponownie?

Możesz powiedzieć, że tak naprawdę nie musiałem udawać, że jesteś rootem, aby utworzyć tę listę. Mogłem po prostu utworzyć listę, a następnie edytować ją, aby odzwierciedlić moją wyobraźnię. Masz rację, nie potrzebujesz fakeroottego. W rzeczywistości, wiedząc, że fakeroottak naprawdę nic nie robi, nie możesz zdobyć żadnej zdolności, której wcześniej nie miałeś.

Ale i o to w tym fakerootwszystkim chodzi, edycja listy może nie być łatwa. Podobnie jak w przypadku pakietu, który można zainstalować w systemie, masz tared, gziped, xzed, bzip2ed lub inny format, który utrzymuje pliki razem i zapamiętuje ich uprawnienia i właścicieli. Czy możesz łatwo zmodyfikować skompresowany plik i edytować własność pliku? Nie wiem o tobie, ale nie mogę wymyślić sposobu.

Czy może istnieć narzędzie, które po skompresowaniu wszystkiego modyfikuje skompresowany plik i programowo edytuje prawa własności i uprawnienia? Tak, może. Możesz więc sfałszować własność przed kompresją lub zmienić ją później. Ludzie Debiana uznali, że to pierwsze jest łatwiejsze.

4. Dlaczego nie po prostu użyć sudo?

Przede wszystkim nie potrzebujesz uprawnień roota do tworzenia oprogramowania i nie potrzebujesz uprawnień roota do ich kompresji. Więc jeśli go nie potrzebujesz, naprawdę musisz być użytkownikiem systemu Windows, aby nawet pomyśleć o uzyskaniu tego pozwolenia. Pomijając sarkazm, możesz nawet nie mieć hasła roota.

Poza tym powiedzmy, że masz uprawnienia roota. Powiedzmy, że chcesz udawać, że plik powinien mieć dostęp tylko do odczytu do katalogu głównego. Więc sudowłaściwie zmieniasz właściciela pliku i uprawnienia root, wychodzisz z powłoki roota i próbujesz spakować wszystko. Niepowodzenie, ponieważ teraz nie możesz już odczytać pliku, ponieważ nie masz dostępu do konta root. Musisz więc sudoskompresować i zbudować pakiet jako root. W efekcie musisz zrobić wszystko jako root.

To jest Zła TM .

Jako program pakujący nie potrzebujesz uprawnień roota i nie powinieneś go otrzymywać. Podczas instalowania pakietu może być konieczne zainstalowanie pliku file ( A) jako root i tam potrzebujesz uprawnień roota. Wszystko po fakerootto, aby było to możliwe. Pozwala to liście programów pakujących Ajako posiadanej przez root dla archiwizatora, tak że gdy użytkownik dekompresuje pakiet, archiwizator wymaga uprawnień roota i tworzy Ajako root.


5
Doskonały zapis, to wyjaśnia.
Christian Long,

1
So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier.Pomogło mi to, gdy ciągle myślałem „dlaczego nie zmodyfikować go później?”.
aaaaaa

1
Dzięki, to wyjaśnia zamieszanie, które miałem po przeczytaniu odpowiedzi @ Mortena
Johannes Schaub - litb

33

AFAIK, fakeroot uruchamia polecenie w środowisku, w którym wydaje się, że ma uprawnienia administratora do manipulowania plikami. Jest to przydatne, aby umożliwić użytkownikom tworzenie archiwów (tar, ar, .deb itp.) Z plikami w nich z uprawnieniami / prawami roota. Bez fakeroot należałoby mieć uprawnienia roota, aby tworzyć pliki składowe archiwów z odpowiednimi uprawnieniami i prawem własności, a następnie spakować je, lub trzeba byłoby tworzyć archiwa bezpośrednio, bez użycia archiwizatora.

fakeroot działa poprzez zastąpienie funkcji biblioteki manipulacji plikami (chmod (), stat () itd.) tymi, które symulują efekt, jaki miałyby rzeczywiste funkcje biblioteki, gdyby użytkownik był naprawdę rootem.

Streszczenie:

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

Sprawdź więcej tutaj: fakeroot


@MaskTheSmokin: Więc fakeroot daje super moc użytkownika tylko do operacji na plikach, prawda.
gkt

@ gkt.pro: Chyba tak.

10
Tak naprawdę nie daje superużytkownikowi mocy, tylko go podrabia - uruchomiony w nim program myśli, że ma uprawnienia roota, podczas gdy tak naprawdę nadal korzysta z normalnych uprawnień użytkownika.
Paŭlo Ebermann

2
Jaka jest różnica między the program running in it thinks it has root privilegesprogramem a uprawnieniami do rootowania? Jeśli mogę to zrobić, rm -rf /a uruchomienie programu uważa, że ​​mam uprawnienia roota ...
użytkownik nieznany

10
@userunknown Być może uda ci się ominąć rmsprawdzenie, czy masz wystarczające uprawnienia, ale samo jądro nie pozwoli ci tego zrobić; unlinkwywołanie systemowe zawiedzie. Obsługa aplikacji nie zależy od samej aplikacji, inaczej możesz napisać własną aplikację, która nie sprawdza uprawnień i robi z nią, co chcesz
Michael Mrozek

11

Użyłem go do skryptów budujących pakiety. Nie byłem pewien, czy osoba uruchamiająca skrypt ma dostęp na poziomie administratora, ale skrypt nadal musiał wygenerować, powiedzmy, plik tar, który zawierał pliki należące do roota. Najprostszym sposobem na to było uruchomienie skryptu budowania pakietów pod fakeroot, co skłoniło archiwizatora do przekonania, że ​​pliki należą do roota i jako takie spakowały je w archiwum. W ten sposób, gdy pakiet został rozpakowany na maszynie docelowej (na innym komputerze), pliki nie należały do ​​dziwnych lub nieistniejących użytkowników.

Myśląc o tym, jedynym miejscem, które widziałem, było zbudowanie jakiegoś archiwum: rootfów systemów wbudowanych, archiwów tar.gz, pakietów rpm, pakietów .deb itp.


1
fakerootjest narzędziem obejścia dla błędnego oprogramowania do pakowania: nie ma powodu, aby być rootem, aby tworzyć takie pakiety, ale ponieważ nie pozwalają one określić uprawnień do plików w inny sposób niż ustawienie ich bezpośrednio w systemie plików, zanim nie masz wybór
pqnet

3

Jednym z typowych zastosowań jest ustalenie, do jakich plików naprawdę chciałby się dostać uszkodzony plik binarny. Oznacza to znalezienie i naprawienie lub obejście błędów spowodowanych przez mocno zakodowane ścieżki i niewłaściwą obsługę wyjątków.


1

Możesz użyć fakeroot bez faktycznych uprawnień roota. Gdybyś miał sui / lub byłbyś w sudostanie zniszczyć swój system za pomocą prostego rm -rf /, ale za pomocą fakeroot najwyżej usunąłbyś swój katalog domowy.


2
To nie tłumaczy potrzeby fakeroot. Możesz usunąć swój katalog domowy jak sam.
JMCF125,

1

Prosta odpowiedź:

su i sudo uruchamiają polecenia jako root. fakeroot nie, poza częściowym ustawieniem piaskownicy.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.