Jaka jest potrzeba polecenia „fakeroot” w systemie Linux

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?

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).

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.

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.

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

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.

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.

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.

Prosta odpowiedź:

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