Чи потребує керування групами доступ до кореня?

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

Я намагаюся створити контрольну групу за допомогою cgcreateкоманди, і, схоже, вона вимагає кореневого доступу на машині. Усі приклади, які я бачив до цього часу, нічого не говорять про те, що потрібно бути кореневим користувачем для створення або зміни груп управління.

Чи дійсно потрібно бути користувачем root? Кінцева мета - написати додаток C ++, яке створює та керує групами управління для управління ресурсами за допомогою API libcgroup. Але додаток C ++ не буде запускати жоден користувач root. Це може бути будь-який звичайний користувач.

Нормальний сценарій , який ви встановили cgcreate, cgset, cgdelete, cggetі т.д. як кореня . Врешті-решт програма / сценарій, який повинен бути обмежений від засмоктування багатьох ресурсів, буде виконаний як звичайний користувач. Отже, налаштування як root, використання та виконання як користувач.

Це робиться з командою -aта -tпараметрами cgcreateкоманди (виконується як root). Тож уже коли ви встановлюєте групу. У моєму випадку:

cgcreate -t ​​monero: monero -a monero: monero -g пам'ять, cpu: monerogroup

де monero - це ім’я майбутнього користувача, який буде виконувати та запускати програму з обмеженнями групи. Про тонку різницю між підпараметрами -aта -tпосиланнями див cgcreate.

людина cgcreate

У більшості випадків це і той самий користувач.

Потім встановіть обмеження (як і раніше як root):

cgset -r memory.limit_in_bytes = $ ((4 * 1024 * 1024 * 1024)) монерогрупа

cgset -r cpu.shares = 128 монерогрупа

Перевірте свої записи, якщо ви хочете:

cgget -g пам'ять: / monerogroup | grep bytes

А потім врешті-решт перемкнути користувача, у моєму випадку користувача monero, і з правої папки:

cgexec -g пам'ять, процесор: monerogroup ./monerod

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

Вплив на безпеку цього в сторону, ви можете встановити setuidбіт

chmod +s /bin/cgcreate
chmod +s /bin/cgdelete

надати користувачам, які не користуються коренем, які працюють із цією кореневою програмою.

Рекомендацією було б потім видалити звичайний доступ користувача

chmod 550 /bin/cgcreate
chmod 550 /bin/cgdelete

і створити спеціальну групу, якій ви хочете дозволити використовувати cgcreate IE cgusers,

groupadd cgusers

і змінити групове членство в цих файлах на цю групу:

chgrp cgusers /bin/cgcreate
chgrp cgusers /bin/cgdelete

Все це буде запускатися під корінь, після чого всі користувачі cgusersгрупи запускатимуться cgcreateі cgdeleteяк root, а не як самі. Вам просто потрібно мати членів, які хотіли б мати цю владу під правильною групою.

Зрештою, під керуванням групами обробляються файлові системи (файли). Можливість створення груп повинна бути лише здатністю створювати каталоги під цим / ними та записувати у файли. Якщо ви монтуєте FS групи з більш досконалими дозволами або якщо ви змінюєте їх дозволи на ходу, певні користувачі повинні мати змогу виконувати завдання. Очевидно, ви не зможете додати ідентифікатори процесу інших користувачів до файлу завдань. Ви зможете лише додати користувача.

Сказавши це, я не впевнений, що сказане є глобальним. Тобто є ймовірність, що певні групи цього не підтримують.

Загалом, найкращим підходом є використання менеджера групи, який потім може бути доручений пов’язати завдання з групою. Я вважаю, що cgmanager робить щось подібне.

Коротка відповідь - ні.

Для створення та присвоєння власності групі ви залежите від привілеїв root. Немає надійного способу обійти це.

Однак ви можете створити групу і призначити право власності певному користувачеві або групі.

Користувач

$ u=$(whoami)
$ sudo mkdir /sys/fs/cgroup/cpuset/${u}
$ sudo chown -R ${u}: /sys/fs/cgroup/cpuset/${u}

Групувати

$ g=MYGROUP && grep ^${g}: /etc/group || echo "Your group doesn't exist. Run \"mkgroup $g\" and repeat this command before you continue." 
$ sudo mkdir /sys/fs/cgroup/cpuset/${g}
$ sudo chgrp -R ${g} /sys/fs/cgroup/cpuset/${g}