Jaka jest potrzeba polecenia `fakeroot` w Linuksie

Wyobraź sobie, że jesteś programista / opiekun pakietu itp. pracujący na zdalnym serwerze. Chcesz zaktualizować zawartość pakietu i odbudować go, pobrać i dostosować jądro z kernel.org i skompilować, itd. Próbując zrobić te rzeczy, dowiesz się, że niektóre kroki wymagają root prawa (UID i GID 0) z różnych powodów (bezpieczeństwo, przeoczone uprawnienia itp.). Nie jest jednak możliwe uzyskanie uprawnień root, ponieważ pracujesz na komputerze zdalnym (i wielu innych użytkowników ma ten sam problem co Ty). To właśnie fakeroot robi: udaje skuteczne UID i GID 0 do środowiska, które ich wymaga.

W praktyce nigdy nie uzyskujesz prawdziwych root uprawnień (w przeciwieństwie do su i sudo, o którym wspominasz).

Komentarze

• więc nie mogę ' t używać zmienić ustawienia systemowe ?? ponieważ polecenie, które ' będziemy uruchamiać, uzna, że ' działa jako root i robi to, co chcemy. won ' t it?
• @mrid Zwróć uwagę na ” W praktyce nigdy nie uzyskujesz prawdziwych uprawnień roota „. Więc odpowiedź brzmi: no

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

$ 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 

Dopóki jesteś w powłoce fakeroot, wygląda na to, że jesteś rootem – o ile nie próbujesz nic robić to naprawdę wymaga uprawnień roota. I właśnie tego potrzebuje narzędzie do pakowania, aby tworzyć opakowania, które będą miały sens na każdej maszynie.

W rzeczywistości, kiedy używasz fakeroot do pakowania, to, co chcesz osiągnąć, to sprawić, by narzędzia uruchamiane przez fakeroot widziały Twoje pliki jako należące do roota. Nic dodać nic ująć. Tak więc w rzeczywistości su lub sudo nie będą działać, aby uzyskać odpowiednią własność pliku.

Komentarze

• Czy podróbka nie jest niebezpieczna? Jeśli utworzę plik z suid bit i rx perm, plik zostanie utworzony, którego właścicielem jest root, i będzie mógł być wykonywany przez każdego, jako root! A może ustawienie bitu suid nie zadziała?
• Nie dobrze. Sam tego wypróbowałem. Podstawowym powodem fakeroot jest uzyskanie roota własności: roota do wbudowanych pakietów bez bycia rootem. Jednak zainstalowane pakiety będą miały odpowiednie uprawnienia.
• To wszystko było bardzo zagmatwane, dopóki nie przeczytałem komentarza @ ntzrmtthihu777 '!
• Przepraszamy, Nie ' nie rozumiem opisu. Dlaczego nie załatać narzędzi, aby wygrywały ' t narzekać, jeśli nie jesteś rootem? Jako pytanie pokrewne: w końcu pliki, które tworzysz pod fakeroot nie są w rzeczywistości własnością roota. Czy nie ' nie oznaczałoby, że po zainstalowaniu takiego pliku .deb wszystkie moje /usr pliki należą do użytkownika o nazwie fakeroot?
• @ JohannesSchaub-litb, nie o to chodzi w '. Pliki nie należą do użytkownika root, ale w powłoce fakeroot wyglądają jak . Gdy pakiet .deb jest tworzony w tej powłoce, właściciel pliku jest odczytywany z systemu plików (który fakeroot przechwytuje i zwraca root) i przechowywane w opakowaniu. Podczas instalowania pakietu dpkg wymaga uprawnień administratora, ponieważ pakiet wskazuje, że właścicielem pliku powinien być root.

Ponieważ odpowiedzi są trudne do zrozumienia (dla mnie) i zajęło mi trochę czasu, aby je zrozumieć ( ten komentarz sprawił, że zrozumiałem), mam nadzieję dać lepsze wyjaśnienie.

1. Co dzieje się w fakeroot

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

Jeśli się nad tym zastanowić, to totalna strata czasu. Dlaczego miałbyś robić rzeczy, które tak naprawdę się nie wydarzyły? To szaleństwo. Mogłeś po prostu tego nie zrobić i nie byłoby żadnej różnicy, ponieważ nie ma po tym śladu.

Poczekaj chwilę …

2. Ślad of fakeroot

Tam mógłby być ślad po fakeroot. Przyjrzyjmy się poleceniom w MortenSickel” odpowiedź , która jest całkiem niezła i zasługuje na uznanie:

$ 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 użycie fakeroot było całkowitą stratą czasu. Ostatecznie, gdybyś nie „t użył fakeroot, uzyskałbyś to samo rzecz.

Subtelna rzecz jest taka:

$ cat root.tst Wow I have root access 

Co oznacza, że zawartość pliku nadal pamięta, że jest katalogiem głównym. Możesz powiedzieć, że nieużywanie fakeroot przyniosł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. Udałem, że jestem root, co jest całkowicie nieskuteczne, i utworzyłem x i y. Udałem, że x należę do myuser i y, że należę do root. W rzeczywistości oba należą do myuser (jak widzimy na końcu), ale ja tylko udawałem , że tak jest.

Następnie stworzyłem listę i zapisałem swoją wyobraźnię w pliku. Później, kiedy ponownie przeglądam plik, widzę, do kogo według mnie powinny należeć pliki. Ponownie, nie są w rzeczywistości własnością osób, które sobie wyobraziłem, po prostu to sobie wyobraziłem.

3. Więc … Dlaczego chcesz to jeszcze raz?

Możesz powiedzieć, że tak naprawdę nie potrzebowałem udawać roota, aby utworzyć ten wpis. Mogłem po prostu utworzyć wpis, a następnie edytować go, aby odzwierciedlić moja wyobraźnia. Masz rację, nie potrzebujesz do tego fakeroot. W rzeczywistości, wiedząc, że fakeroot w rzeczywistości nic nie robi, nie możesz zdobyć umiejętności, których wcześniej nie miałeś.

Ale , a na tym właśnie polega fakeroot, edycja listy może być nietrywialna.Tak jak w przypadku pakietu, który można zainstalować w systemie, masz tar ed, gzip ed, xz ed, bzip2 ed lub jakikolwiek 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 jak wy, ale nie potrafię wymyślić sposobu.

Czy mogłoby 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 albo sfałszować prawa własności przed kompresją, albo zmienić je później. Ludzie Debiana uznali, że to pierwsze jest łatwiejsze.

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

Po pierwsze, nie potrzebujesz uprawnień roota do tworzenia oprogramowania i nie potrzebujesz uprawnień roota, aby je skompresować. Więc jeśli go nie potrzebujesz, musiałbyś naprawdę być użytkownikiem Windows, żeby nawet pomyśleć o uzyskaniu tego uprawnienia. Ale odkładając na bok sarkazm, możesz nawet nie mieć hasła roota.

Poza tym, powiedzmy, że masz uprawnienia roota. I powiedzmy, że chcesz udawać, że plik powinien mieć dostęp do odczytu tylko do korzeń. Więc sudo, faktycznie zmieniasz właściciela pliku i uprawnienia na root, wychodzisz z powłoki roota i próbujesz spakować wszystko. Nie udało się, ponieważ teraz nie możesz już odczytać pliku, ponieważ nie masz uprawnień administratora. Musisz więc sudo i skompresować i zbudować pakiet jako root. Skutecznie, musisz to zrobić wszystko jako root.

To jest zła ^TM .

Jako osoba pakująca nie potrzebujesz uprawnień roota i nie powinieneś jej otrzymywać. Kiedy gdy instalujesz pakiet, może być konieczne zainstalowanie jakiegoś pliku (A) jako root i tam potrzebujesz uprawnień roota. Wszystko, co robi fakeroot, ma na celu umożliwienie tego. Pozwala to na listę programu pakującego A jako należącą do roota archiwizatora, tak że gdy pakiet jest dekompresowany przez użytkownika, archiwizator żąda uprawnień administratora i tworzy A jako należący do roota.

Komentarze

• Doskonały napis, to wyjaśnia.
• So either you could fake the ownerships before compressing, or change them after. Debian people decided the former is easier. Pomogło mi to, ponieważ wciąż myślałem ' dlaczego nie zmodyfikować go po? '.
• Dzięki, to wyjaśnia zamieszanie, które miałem po przeczytaniu odpowiedzi @Morten '

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

fakeroot działa poprzez zamianę funkcji bibliotecznych do manipulacji plikami (chmod (), stat () itp.) na takie, które symulują efekt, jaki miałyby prawdziwe funkcje biblioteczne, gdyby użytkownik naprawdę był rootem.

Streszczenie:

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

Sprawdź więcej tutaj: fakeroot

Komentarze

• @MaskTheSmokin: Więc fakeroot daje ci moc super użytkownika tylko do operacji na plikach, prawda.
• Tak naprawdę to nie daje moc superużytkownika, tylko ją udaje – działający w nim program myśli, że ma uprawnienia roota, podczas gdy tak naprawdę nadal używa zwykłych uprawnień użytkownika '.
• Jaka jest różnica między the program running in it thinks it has root privileges a programem mającym uprawnienia roota? Jeśli mogę wykonać rm -rf / i program, po uruchomieniu go myśli, że mam uprawnienia roota …
• @userunknown Możesz ominąć rm ' s sprawdź, czy masz wystarczające uprawnienia, ale samo jądro nie ' na to nie pozwoli ; wywołanie systemowe unlink nie powiedzie się. ' nie zależy wyłącznie od aplikacji do obsługi uprawnień, lub ' nie będziesz w stanie napisać własnej aplikacji, która nie ' t sprawdzaj uprawnienia i rób z tym co chcesz
• Przykład wyjaśniający potrzebę fakeroot byłby fantastyczny. Widzę zastosowania fakeroot, ale nie ' nie rozumiem, dlaczego ludzie nie mogą ' ominąć uprawnień roota do tego stopnia, że ' łatwiej to sfałszować.

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 budującego pakiet w fakeroot, co skłoniło archiwizera do przekonania, że pliki należą do roota i spakowały je jako takie w archiwum. W ten sposób, gdy pakiet został rozpakowany na maszynę docelową (w ogóle na innym komputerze), pliki nie należały do dziwnych lub nieistniejących użytkowników.

Myśląc o tym, jedyne miejsce, które widziałem, to budowanie jakiegoś rodzaju archiwum: rootfs systemów wbudowanych, archiwa tar.gz, pakiety rpm, pakiety .deb itp.

Komentarze

• fakeroot to obejście problemu z błędnym oprogramowaniem do pakowania: nie ma powodu, dla którego musisz być rootem, aby tworzyć takie pakiety, b ut, ponieważ nie ' t pozwalają na określenie uprawnień do plików w jakikolwiek inny sposób niż ustawienie ich bezpośrednio w systemie plików, zanim nie masz wyboru

Jednym z typowych zastosowań jest sprawdzenie, do jakich plików naprawdę chciał uzyskać dostęp uszkodzony plik binarny. Oznacza to znalezienie i naprawienie lub obejście błędów spowodowanych przez zakodowane na stałe ścieżki i niewłaściwą obsługę wyjątków.

Możesz używaj fakeroot bez posiadania uprawnień roota. Gdybyś miał su i / lub sudo, byłbyś w stanie zniszczyć swój system za pomocą prostego rm -rf /, ale przy użyciu fakeroot co najwyżej usuniesz swój katalog domowy.

Komentarze

• To nie ' t wyjaśnij potrzebę fakeroot. Możesz usunąć swój katalog domowy jako siebie.

Prosta odpowiedź:

su i sudo uruchamiają polecenia jako root. fakeroot tego nie robi, poza częściowym układem piaskownicy.