Яка потреба в команді `fakeroot` в Linux

Навіщо нам взагалі потрібна fakerootкоманда? Чи не можемо ми просто використати команди sudoабо suкоманди?

На сторінці чоловіка написано:

fakeroot - запустіть команду в середовищі, підробляючи привілеї root для маніпулювання файлом

About.com говорить:

Дає підроблене середовище кореня. Цей пакет призначений для того, щоб увімкнути щось на зразок: dpkg-buildpackage -rfakerootтобто усунути необхідність стати коренем для складання пакету. Це робиться шляхом установки LD_PRELOADна libfakeroot.so, який забезпечує обгортки навколо getuid, chown, chmod, mknod, stat, ..., тим самим створюючи підроблені кореневої середовища. Якщо ви нічого з цього не розумієте, вам це не потрібно fakeroot!

Моє запитання полягає в тому, яка спеціальна мета вирішує це просто suчи sudoні? Наприклад, для упаковки всіх встановлених пакетів в ubuntu ми даємо таку команду:

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

Чи можемо ми виконати вищезазначену команду з sudo або su замість фальшивки так:

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

Редагувати:

Запуск:

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

дає мені цю помилку:

каталог управління має погані дозволи 700 (має бути> = 0755 і <= 0775)

Будь-яка причина чому?

Уявіть, що ви розробник / підтримувач пакетів тощо. Працюєте на віддаленому сервері. Ви хочете оновити вміст пакета та відновити його, завантажити та налаштувати ядро ​​з kernel.org та створити його тощо. Намагаючись виконувати ці дії, ви дізнаєтесь, що для деяких кроків потрібно мати rootправа ( UIDі GID0) з різних причин (безпека, недозволені дозволи тощо). Але отримати rootправа неможливо , оскільки ви працюєте на віддаленій машині (і багато інших користувачів мають ту ж проблему, що і ви). Це саме те, що саме fakerootробить: він видає себе ефективним UIDі GIDвідповідає 0 навколишньому середовищу, яке цього вимагає.

На практиці ви ніколи не отримуєте реальних rootпільг (навпаки suі того, sudoщо ви згадуєте).

Щоб чітко побачити різницю між факером та справжнім судо / су, просто зробіть:

$ 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

Поки ви знаходитесь в оболонці підробленого файлу, це виглядає, як якщо ви кореневий, - поки ви не намагаєтесь робити нічого, що дійсно потребує привілеїв root. І саме це потрібно для пакувального інструменту, щоб зробити пакети, які матимуть сенс на будь-якій машині.

Насправді, коли ви використовуєте fakeroot для упаковки, то, що ви хочете досягти, - це зробити інструменти, які ви запускаєте під фальшивим файлом, щоб побачити ваші файли як власність root. Нічого більше, нічого менше. Тож насправді su або sudo не працюватимуть для отримання права власності на файл.

Оскільки відповіді важко зрозуміти (самому), і для того, щоб зрозуміти це, потрібно було трохи думати ( цей коментар змусив мене зрозуміти це), я збираюся дати пояснення краще.

1. Що відбувається у підробці

Нічого іншого, ніж те, що відбувається з вашим власним користувачем. Абсолютно нічого більше. Якщо ви fakeroot(який при дзвінку дає вам нову оболонку, як sudoби хотіли), робите вигляд, що робите речі, на які вам потрібен дозвіл та виходите, абсолютно нічого не трапиться.

Якщо ви подумаєте про це, це повна марна трата часу. Чому б ти робив речі, які насправді не відбудуться? Це божевільно. Ви могли просто не зробити нічого з цього, і різниці не було б, оскільки про це немає і сліду.

Почекай хвилинку...

2. Слід фальшивки

Тут може залишитися і слід fakeroot. Давайте подивимось на команди у відповіді MortenSickel, які є досить приємними та заслуговують на підсумок:

$ 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

З першого погляду, схоже, що використання fakerootбуло цілком марною тратою часу. Зрештою, якби ти не використовував fakeroot, ти отримав би те саме.

Тут найтонше:

$ cat root.tst
Wow I have root access

Що означає, що вміст файлу все ще пам’ятає, що він є коренем. Ви можете сказати, що не використання fakerootдало б однакові результати. Ви праві, цей приклад занадто простий.

Візьмемо ще один приклад:

$ 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

Подивимося, що сталося. Я робив вигляд root, що абсолютно неефективний, і створив xі y. Я робив вигляд, xщо належу myuserі yналежу root. Вони насправді належать обом myuser(як ми бачимо врешті-решт), але я просто робив вигляд, що це таке.

Потім я створив список і зберег свою уяву до файлу. Пізніше, коли я оглянувся на файл, я можу побачити, хто я уявив, якими файлами повинні володіти. Знову ж таки, насправді вони не належать людям, яких я уявляв, я просто це просто уявляв.

3. Отже ... Чому ти хочеш цього знову?

Ви можете сказати, що мені не потрібно було підробляти корінь для створення цього списку. Я міг просто створити лістинг, а потім відредагував його, щоб відобразити мою уяву. Ви маєте рацію, вам цього не потрібно було fakeroot. Насправді, знаючи, що fakerootнасправді нічого не робить, ви, можливо, не здобули жодної здатності, якої не мали раніше.

Але , і це fakerootвсе, про що йдеться, редагування списку може бути нетривіальним. Як і у випадку з пакетом, який можна встановити у вашій системі, у вас є tared, gziped, xzed, bzip2ed або будь-який інший формат, який зберігає ваші файли разом і пам’ятає їх права та власники. Чи можете ви легко змінити стислий файл і відредагувати право власності на файл? Я не знаю про тебе, але я не можу придумати спосіб.

Чи може бути створений інструмент, який, коли все стискається, він змінює стислий файл і програмно редагує права власності та дозволи? Так, могли. Тож ви можете підробити права власності перед тим, як стиснути, або змінити їх після. Люди Debian вирішили, що колись простіше.

4. Чому не просто використовувати sudo?

Перш за все, вам не потрібні кореневі привілеї для створення програмного забезпечення, і вам не потрібні привілеї root для їх стиснення. Тож якщо він вам не потрібен, вам доведеться справді бути користувачем Windows, щоб навіть думати про отримання цього дозволу. Але в бік сарказму, можливо, у вас навіть немає пароля root.

Крім того, скажімо, у вас є кореневі дозволи. Скажімо, ви хочете зробити вигляд, що файл повинен мати доступ для читання лише до кореня. Отже, ви sudoфактично змінюєте власника файлу та дозволи на нього root, виходите з кореневої оболонки і намагаєтесь упакувати все. Помилка, оскільки тепер ви вже не можете прочитати файл, оскільки у вас немає доступу до кореня. Тож вам доведеться sudoстиснути і скласти пакет як корінь. Ефективно, ви повинні робити все як root.

Це погана ^ТМ .

Як пакувальник, вам не потрібні кореневі дозволи, і ви не повинні їх отримувати. Під час встановлення пакета вам може знадобитися встановити якийсь файл ( A) як root, і саме там вам потрібні дозволи root. Все fakeroot, щоб зробити це можливим. Це дозволяє списку пакувальників Aяк власника root для архіватора, так що, коли пакунок декомпресується користувачем, архіватор вимагає кореневого дозволу і створює Aяк належить root.

AFAIK, fakeroot запускає команду в середовищі, де, схоже, є кореневі привілеї для обробки файлів. Це корисно для того, щоб дозволити користувачам створювати архіви (tar, ar, .deb тощо) з файлами в них із кореневими правами / правами власності. Без фальшивки потрібно мати кореневі привілеї, щоб створити складові файли архівів з правильними дозволами та правом власності, а потім упакувати їх, або потрібно було б створити архіви безпосередньо, не використовуючи архіватор.

fakeroot працює, замінюючи функції бібліотеки маніпуляцій файлами (chmod (), stat () тощо) на ті, що імітують ефект, який мали б реальні функції бібліотеки, якби користувач справді був root.

Конспект:

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

Перевірте більше тут: фальшивка

Я використовував його для створення сценаріїв створення пакетів. Я не був впевнений, що особа, що працює із сценарієм, має доступ до кореневого рівня, але сценарій все-таки потребував для створення, скажімо, файлу tar, який містив файли, що належать до root. Найпростіший спосіб зробити це - запустити скрипт створення пакету під фальшивим файлом, який надумав архіватора вважати, що файли належать до кореня, і запакував їх як такий у архіві. Таким чином, коли пакет був розпакований на машину призначення (на іншій машині взагалі), файли не належали дивним або неіснуючим користувачам.

Думаючи про це, єдине, що я бачив, це було для створення якогось архіву: коренів вбудованих систем, архівів tar.gz, пакетів rpm, пакетів .deb тощо.

Одне поширене використання - дізнатися, до яких файлів невдалий двійковий файл дійсно хотів отримати доступ. Тобто з’ясування та виправлення або усунення помилок, спричинених жорсткими кодованими шляхами та неправильним поводженням з винятками.

Ви можете використовувати підробку, фактично не маючи привілеїв root. Якби у вас був suі / або sudoви могли б знищити вашу систему за допомогою простого rm -rf /, але максимум підробленого, ви видалили б свій домашній каталог.

Проста відповідь:

Команди su та sudo запускають як root. fakeroot не робить, поза його частковою облаштуванням пісочниці.