Як працюють дозволи на Linux, коли процес працює як певна група?

Це те, про що я не зміг знайти багато інформації, тому будь-яка допомога буде вдячна.

Моє розуміння таке. Візьміть такий файл:

-rw-r-----  1 root        adm   69524 May 21 17:31 debug.1

Користувач philне може отримати доступ до цього файлу:

phil@server:/var/log$ head -n 1 debug.1
cat: debug.1: Permission denied

Якщо philйого додати до admгрупи, він може:

root@server:~# adduser phil adm
Adding user `phil' to group `adm' ...
Adding user phil to group adm
Done.
phil@server:/var/log$ head -n 1 debug.1
May 21 11:23:15 server kernel: [    0.000000] DMI: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5.1-0-g8936dbb-20141113_115728-nilsson.home.kraxel.org 04/01/2014

Якщо, однак, процес запускається під час явного встановлення user:groupна phil:philнього, він не може прочитати файл. Процес розпочався так:

nice -n 19 chroot --userspec phil:phil / sh -c "process"

Якщо процес запускається як phil:adm, він може прочитати файл:

nice -n 19 chroot --userspec phil:adm / sh -c "process"

Тож питання справді таке:

Що особливого у запуску процесу з певним комбо / користувачем групи, що перешкоджає процесу доступу до файлів, що належать додатковим групам цього користувача, і чи існує спосіб цього?

Процес запускається з uid та gid. Обоє мають призначені їм дозволи. Ви можете зателефонувати до chroot з користувацькою специфікацією користувача та групи, де власне користувач не в цій групі. Потім процес виконується з користувачами uid та заданими групами gid.

Дивіться приклад. У мене є користувач, який називається user, і він в групі student:

root@host:~$ id user
uid=10298(user) gid=20002(student) groups=20002(student)

У мене є такий файл:

root@host:~$ ls -l file
-rw-r----- 1 root root 9 Mai 29 13:39 file

Він не може його прочитати:

user@host:~$ cat file
cat: file: Permission denied 

Тепер я можу виконати catпроцес у контексті користувача userТА групи root. Тепер процес котів має необхідні дозволи:

root@host:~$ chroot --userspec user:root / sh -c "cat file"
file contents

Цікаво подивитися, що idсказано:

root@host:~$ chroot --userspec user:root / sh -c "id"
uid=10298(user) gid=0(root) groups=20002(student),0(root)

Хм, але користувач userне в цій групі ( root). Звідки береться idїї інформація? Якщо викликано без аргументів, idвикористовує системні виклики getuid(), getgid()та getgroups(). Отже, контекст процесу idнадрукований сам по собі. Цей контекст ми змінили --userspec.

Коли викликається аргументом, він idпросто визначає групові призначення користувача:

root@host:~$ chroot --userspec user:root / sh -c "id user"
uid=10298(user) gid=20002(student) groups=20002(student)

До вашого питання:

Що особливого у запуску процесу з певним комбо / користувачем групи, що перешкоджає процесу доступу до файлів, що належать додатковим групам цього користувача, і чи існує спосіб цього?

Ви можете встановити контекст процесу безпеки, необхідний для вирішення будь-якої задачі, яку потрібно виконати. Кожен процес має набір uid та gid, під яким він працює. Зазвичай процес "приймає" користувачів, що викликають uid та gid, як його контекст. Я маю на увазі, що це означає, що ядро ​​робить, інакше це буде проблема безпеки.

Отже, насправді це не той користувач, який не має дозволу на читання файлу, а його дозвіл на процес ( cat). Але процес запускається з uid / gid виклику користувача.

Таким чином, вам не потрібно бути в певній групі, щоб процес запускався з вашим uid та gid цієї групи.

Використовуючи --userspecопцію on, chrootвказує користувача та одну групу, яку слід використовувати під час запуску chroot. Для визначення додаткових груп потрібно також скористатися --groupsпараметром.

За замовчуванням процеси успадковують первинні та додаткові групи користувача, який їх запускає, але, використовуючи, --userspecви говорите, chmodщоб перекрити це, використовуючи вказану єдину групу.

Детальна документація дозволів у Linux доступна на сторінці credentials(7).

Коли ви входите в Linux, процес входу¹ - після підтвердження ви можете увійти як phil - отримує uid phil та групи, до яких належить, встановлюючи їх як процес, який потім починається як ваша оболонка. Групи uid, gid та доповнення є властивістю процесу.

Будь-яка пізніша програма, запущена після цього, є нащадком цієї оболонки і просто отримує копію цих облікових даних. * Це пояснює, чому зміна прав користувача не впливає на запущені процеси. Однак зміни будуть взяті під час наступного входу.

* Виняток становлять програми, для яких встановлені встановлені або встановлені біти, які матимуть інший ефективний ідентифікатор користувача . Це використовується, наприклад, в su (1), тому він може працювати з rootпривілеями, навіть коли виконується phil.

Після того, як ви додасте philдо admгрупи, він може запустити su phil, і suвін запуститься як root- переконається, що він дійсно надає пароль phil, а потім висадить його в оболонку з типом uid, gid та додаткових груп, до яких належить phil. Оскільки це робиться після додавання користувача до групи, ця оболонка вже буде в admгрупі.

Я не вважаю chroot (1) найбільш підходящою програмою для запуску як іншого користувача , але це, безумовно, робить роботу. Параметр --userspec phil:philзмушує запускати його з uid philта gid phil. Не встановлюються додаткові групи (для цього ви б надали --groups). Таким чином, дитячий процес не знаходиться в admгрупі.

Більш нормальний спосіб запустити процес як phil su phil -c "process". Оскільки suзавантажуються групи uid, gid та додаткові з інформації бази даних користувачів, processматимуть ті самі облікові дані, якими користувач користується.

¹ Це може бути логін (1) , sshd, su, gdb або інші програми. Крім того, це, ймовірно, керується за допомогою модулів пам’яті.