Керування користувачами та групами є однією з основ безпеки Linux. Від того, як налаштовані облікові записи, системні групи та адміністративні привілеї, залежить, хто може працювати із сервером, запускати служби, змінювати конфігурації та отримувати доступ до важливих даних. У другій частині серії «Linux для DevOps і DevSecOps» розберемо ідентифікатори UID і GID, системні файли облікових записів, створення та видалення користувачів, керування групами, а також механізми su і sudo.
У першій частині серії ми розглянули файлову систему Linux, навігацію через термінал, пошук файлів і роботу з основними командами. Тепер перейдемо до того, як система визначає користувачів, розмежовує їхні повноваження та контролює доступ до ресурсів.
На звичайному домашньому комп’ютері ці механізми можуть залишатися майже непомітними. Однак на Linux-сервері одночасно працюють десятки системних служб, автоматизованих процесів і користувацьких облікових записів. Кожен із них повинен мати лише ті можливості, які потрібні для виконання конкретних завдань.
Для DevOps це питання стабільності та правильного адміністрування інфраструктури. Для DevSecOps до цього додається контроль привілеїв, захист системних облікових записів і зменшення наслідків потенційної компрометації.
У Linux користувач має не лише ім’я, яке відображається в терміналі або використовується для входу. Насамперед система ідентифікує облікові записи за числовими значеннями UID (User Identifier) і GID (Group Identifier). UID визначає користувача, а GID позначає групу. Саме ці ідентифікатори використовуються для перевірки прав доступу до файлів, каталогів та інших системних ресурсів. Людині зручніше працювати з іменами на кшталт admin, deployer або postgres, але для ядра важливі відповідні числові значення.
Наприклад, обліковий запис deployer може мати UID 1001 і основну групу з GID 1001. Коли користувач створює файл, файловій системі зазвичай передаються числові ідентифікатори його власника та групи. Ця особливість має важливі наслідки. Припустімо, на сервері існував користувач deployer із UID 1001, який створив кілька файлів. Пізніше його обліковий запис видалили, а нового користувача з тим самим ім’ям створили вже з UID 1002. Новий deployer не стане автоматично власником старих файлів, оскільки вони досі пов’язані з UID 1001.
Зворотна ситуація ще цікавіша з погляду безпеки. Якщо новому користувачу призначити той самий UID 1001, система розглядатиме його як власника файлів із цим ідентифікатором, навіть якщо раніше вони належали іншому обліковому запису. Саме тому під час перенесення даних між серверами, відновлення резервних копій або видалення користувачів важливо враховувати не лише імена, а й числові ідентифікатори.
Кожен локальний обліковий запис Linux зазвичай описується кількома основними характеристиками:
Домашній каталог призначений для користувацьких файлів і персональних налаштувань. Shell визначає програму, яка використовується як оболонка під час входу. Наприклад, це може бути /bin/bash, /bin/zsh або спеціальна програма /usr/sbin/nologin, яка відмовляє в інтерактивному вході.
Щоб дізнатися, під яким користувачем зараз виконується команда, використовується whoami:
whoami
Команда покаже ім’я ефективного користувача поточного процесу. Це зручно, коли ви працюєте з кількома обліковими записами або перемикаєтеся між ними через sudo та su.
Для отримання детальнішої інформації існує команда id:
id
Приклад результату:
uid=1001(deployer) gid=1001(deployer) groups=1001(deployer),27(sudo)
Тут можна побачити UID, основну групу та всі додаткові групи користувача. Якщо потрібен лише числовий ідентифікатор, використовуються параметри -u і -g:
id -u id -g
Перша команда виведе UID, друга – основний GID. Також можна перевірити характеристики іншого облікового запису, якщо зазначити його ім’я:
id root id www-data
Для отримання повного запису користувача рекомендується використовувати getent:
getent passwd root
На відміну від прямого перегляду /etc/passwd, команда getent звертається до налаштованих джерел NSS (Name Service Switch). Тому вона може працювати не лише з локальними обліковими записами, а й із користувачами, інформація про яких надходить із LDAP або інших систем ідентифікації. Це особливо важливо для корпоративної інфраструктури, де облікові записи можуть централізовано керуватися через зовнішні служби.
Не всі облікові записи Linux належать людям. Значна їх частина створюється операційною системою або встановленим програмним забезпеченням для запуску окремих служб. Умовно користувачів можна поділити на звичайних, системних і привілейованих. Ці категорії відрізняються призначенням, набором можливостей і типовими діапазонами UID.
У багатьох дистрибутивах звичайні користувачі отримують UID починаючи з 1000, тоді як менші значення переважно зарезервовані для системних облікових записів. Водночас конкретні діапазони залежать від дистрибутива, конфігурації та способу створення користувачів.
Налаштування можна перевірити у файлі /etc/login.defs:
grep -E '^(UID_MIN|UID_MAX|SYS_UID_MIN|SYS_UID_MAX)' /etc/login.defs
Це дозволить побачити діапазони, які використовують відповідні утиліти керування обліковими записами. Особливе місце займає користувач root, який має UID 0. Він традиційно використовується для повного адміністрування системи та має можливість обходити багато стандартних перевірок прав доступу. Проте це не означає абсолютної відсутності обмежень: сучасний Linux також використовує механізми capabilities, MAC-політики, простори імен та інші засоби контролю. Водночас отримання повного контролю над root у звичайному серверному середовищі часто означає компрометацію всієї системи.
Інший приклад – системний користувач www-data, який у Debian та Ubuntu часто використовується вебсерверними процесами. Якщо вебсервер запускається від окремого непривілейованого користувача, потенційно небезпечний код у його процесі не повинен автоматично отримувати повноваження адміністратора. Саме на цьому ґрунтується один із базових принципів безпеки: служби мають працювати з мінімально необхідними привілеями.
Щоб переглянути локальні облікові записи з UID менше 1000, можна виконати:
awk -F: '$3 > 0 && $3 < 1000 {print $1, $3, $7}' /etc/passwd
Тут awk використовує двокрапку як роздільник полів, після чого відбирає записи за UID. Така команда дає змогу побачити імена системних користувачів, їхні числові ідентифікатори та оболонки, призначені для входу.
Для багатьох системних акаунтів використовується /usr/sbin/nologin або /bin/false. Це дозволяє відмовити в стандартному інтерактивному вході, хоча саме по собі не забороняє всіх способів запуску процесів від імені такого користувача.
Також у Linux можна зустріти обліковий запис nobody. Він часто застосовується для операцій, яким не потрібна прив’язка до звичайного користувача, зокрема в окремих сценаріях NFS або ізоляції процесів. У багатьох системах для нього використовується UID 65534, але це значення не є універсальним.
Важливо розуміти, що назва nobody сама по собі не робить процес безпечним. Якщо програма має доступ до важливих ресурсів через файлові дозволи, групи чи інші механізми, такий доступ може залишатися навіть у непривілейованому контексті.
Коли із сервером працює кілька людей або служб, налаштовувати доступ окремо для кожного користувача незручно. Саме для цього Linux підтримує групи. Група об’єднує користувачів, яким потрібні спільні права на певні ресурси. Наприклад, у команді розробки кільком інженерам може бути необхідний доступ до одного каталогу з конфігураціями або файлами застосунку.
Замість того щоб змінювати власника кожного файлу чи налаштовувати права для кожного облікового запису окремо, можна створити групу developers, додати до неї потрібних людей та призначити її власником відповідного каталогу.
У Linux розрізняють основну (primary) і додаткові (supplementary) групи. Кожен користувач має одну основну групу, її GID зазначається в записі облікового запису. Крім того, користувач може бути учасником кількох додаткових груп, які надають доступ до інших ресурсів.
За звичайних умов нові файли отримують групу відповідно до ефективного GID процесу. Однак поведінка може змінюватися залежно від налаштувань каталогу, зокрема біта SGID, тому в спільних робочих директоріях група файлу не завжди збігається з основною групою користувача.
Перевірити поточне членство в групах можна за допомогою:
groups
Для конкретного користувача:
groups deployer
Детальнішу інформацію з числовими GID покаже команда:
id deployer
А щоб переглянути запис конкретної групи:
getent group developers
У результаті можна отримати рядок такого вигляду:
developers:x:1500:deployer,maria
Це означає, що група developers має GID 1500, а користувачі deployer і maria зазначені як її додаткові учасники. При цьому getent group не обов’язково показує всіх користувачів, для яких ця група є основною. Щоб отримати повне уявлення про членство конкретної людини, зручніше використовувати id.
Групи також можуть надавати дуже широкі повноваження. Наприклад, користувачі, які мають доступ до стандартного Docker daemon через групу docker, за звичайної конфігурації можуть фактично отримати можливості, еквівалентні root на хості. Тому додавання до адміністративних або технічно привілейованих груп потрібно розглядати як операцію безпеки, а не просто спосіб прибрати помилку доступу.
У звичайній локальній конфігурації Linux для керування обліковими записами використовує кілька системних файлів. Найважливішими серед них є /etc/passwd, /etc/shadow, /etc/group і /etc/gshadow.
Вони містять інформацію про користувачів, їхні паролі, групи та деякі параметри автентифікації. При цьому доступ до цих файлів відрізняється залежно від характеру інформації, яка в них зберігається.
Файл /etc/passwd містить локальні записи користувачів. Його назва історично пов’язана з паролями, однак у сучасних системах самі хеші паролів зазвичай зберігаються окремо.
Переглянути файл можна стандартною командою:
cat /etc/passwd
Кожен рядок описує окремий обліковий запис і складається із семи полів, розділених двокрапками.
Наприклад:
deployer:x:1001:1001:Deploy User:/home/deployer:/bin/bash
Поля мають таке значення:
У більшості Linux-систем /etc/passwd доступний для читання звичайним користувачам. Це необхідно для роботи багатьох програм, які перетворюють числові ідентифікатори на імена.
Раніше хеші паролів могли зберігатися безпосередньо в цьому файлі. Такий підхід створював додаткові ризики, адже будь-який користувач із правом читання міг отримати хеші та спробувати підібрати до них паролі в офлайн-режимі. Саме тому інформацію, пов’язану з паролями, винесли до окремого захищеного файлу.
Файл /etc/shadow містить локальні дані автентифікації, зокрема хеші паролів і параметри їхнього терміну дії. На відміну від /etc/passwd, цей файл не призначений для загального читання. У типовій системі доступ до нього обмежений root та відповідними системними механізмами.
Для перегляду конкретного запису в навчальному середовищі можна виконати:
sudo getent shadow deployer
Залежно від налаштувань доступу та NSS команда покаже відповідний запис, якщо він доступний. Пароль у /etc/shadow зазвичай зберігається не у відкритому вигляді, а як результат криптографічного хешування. У багатьох системах використовуються схеми, які також включають випадкову сіль та параметри обчислювальної складності.
Наприклад, префікс $6$ традиційно позначає SHA-512-crypt, а $y$ використовується для yescrypt. Конкретний алгоритм залежить від дистрибутива та його конфігурації.
Крім даних пароля, записи містять параметри його старіння: дату останньої зміни, мінімальний і максимальний терміни використання, період попередження та інші характеристики.
Для перегляду цих параметрів не обов’язково читати /etc/shadow безпосередньо. Можна скористатися командою:
sudo chage -l deployer
Вона показує інформацію про термін дії пароля й відповідні обмеження. Окремо потрібно враховувати значення ! і * у полі пароля. Вони можуть позначати заблоковану або непридатну для автентифікації парольну комбінацію. Однак це не завжди означає повне блокування самого облікового запису, адже вхід через SSH-ключ або інші механізми автентифікації може залишатися можливим.
Файл /etc/group містить інформацію про локальні групи. Його записи також розділяються двокрапками.
Наприклад:
developers:x:1500:deployer,maria
Перший елемент визначає назву групи, другий описує поле пароля групи, третій містить GID, а четвертий перелічує додаткових учасників.
Для перегляду всього файлу можна виконати:
cat /etc/group
Файл /etc/gshadow використовується для захищеної інформації про групи, зокрема паролів груп, їхніх адміністраторів і списків членства. У звичайному адмініструванні працювати з ним безпосередньо доводиться рідко.
Важливо не редагувати ці системні файли звичайним текстовим редактором без необхідності. Для зміни облікових записів існують спеціалізовані утиліти, які враховують структуру даних і допомагають уникати конфліктів під час одночасного редагування.
Якщо ручне редагування все ж необхідне, для цього передбачені:
sudo vipw sudo vipw -s sudo vigr sudo vigr -s
Ці команди призначені для роботи відповідно з /etc/passwd, /etc/shadow, /etc/group та /etc/gshadow.
Після внесення змін можна перевірити узгодженість локальних записів:
sudo pwck sudo grpck
Однак навіть ці утиліти не замінюють резервного копіювання та обережного планування змін, особливо на робочих серверах.
Коли до команди приєднується новий інженер або для застосунку потрібен окремий системний обліковий запис, адміністратора цікавить не лише створення користувача, а й правильне налаштування його середовища та привілеїв.
Одним з основних інструментів є useradd. Він дозволяє створювати локальні облікові записи з потрібними характеристиками: домашнім каталогом, оболонкою, групами, UID та іншими параметрами.
Наприклад, для створення звичайного користувача з ім’ям deployer можна виконати:
sudo useradd -m -s /bin/bash deployer
Параметр -m створює домашній каталог, а -s /bin/bash призначає Bash як оболонку. Зазвичай для нового користувача також створюється відповідний запис у системних файлах і, залежно від конфігурації дистрибутива, однойменна основна група.
Перевірити результат можна командами:
id deployer getent passwd deployer ls -ld /home/deployer
Якщо користувачу потрібна додаткова інформація в полі GECOS, її можна вказати під час створення через параметр -c:
sudo useradd -m -s /bin/bash -c "Deployment Engineer" deployer2
Для автоматизованих служб часто створюють системні облікові записи без інтерактивного входу. Наприклад:
sudo useradd -r -s /usr/sbin/nologin -c "Monitoring Service" monitor-svc
Параметр -r указує, що створюється системний користувач, а /usr/sbin/nologin забороняє стандартний інтерактивний вхід через цю оболонку.
Такий підхід дозволяє запускати службу від окремого непривілейованого користувача замість root. Це зменшує ризики у випадку вразливості застосунку, адже процес не повинен отримувати повноваження, які йому не потрібні.
Для встановлення пароля використовується passwd:
sudo passwd deployer
Система запропонує ввести новий пароль і повторити його. Введені символи зазвичай не відображаються на екрані, що є нормальною поведінкою термінала.
За потреби можна вимагати зміну пароля під час наступного входу:
sudo passwd -e deployer
Це корисно, коли адміністратор створює новий обліковий запис і передає його співробітнику. У такому разі тимчасовий пароль не повинен залишатися постійним.
Для автоматизованого створення великої кількості облікових записів існує chpasswd, але передавати паролі безпосередньо в командному рядку або зберігати їх у скриптах у відкритому вигляді небезпечно. Для корпоративної інфраструктури доцільніше використовувати централізоване керування секретами, обліковими записами та доступом.
Під час створення домашнього каталогу useradd -m зазвичай копіює до нього стандартні файли з /etc/skel. Це спеціальний каталог шаблонів, який дозволяє задавати базове середовище для нових облікових записів.
Перевірити його вміст можна так:
ls -la /etc/skel
Там можуть розміщуватися .bashrc, .profile, .bash_logout та інші конфігураційні файли. Вони визначають частину поведінки командної оболонки, змінні середовища й персональні налаштування.
Наприклад, якщо в організації потрібно, щоб нові користувачі отримували однакові налаштування Git, адміністратор може додати відповідний шаблон до /etc/skel. Після цього він застосовуватиметься до нових домашніх каталогів, створених із використанням такого шаблону.
Водночас зміни у /etc/skel не оновлюють автоматично домашні каталоги користувачів, які вже існують.
Крім цього, поведінку нових облікових записів можуть визначати /etc/default/useradd, /etc/login.defs, глобальні налаштування оболонки та політики автентифікації.
Для DevOps важливо враховувати ці особливості під час автоматизованого розгортання серверів, щоб однакові сценарії створення користувачів не призводили до несподіваних відмінностей між системами.
Коли користувач створює файл або каталог, система повинна визначити, хто зможе читати, змінювати або відкривати цей об’єкт. На результат впливають запитані програмою права, поточна маска umask, а іноді й ACL та інші властивості файлової системи. Зараз розглянемо лише базовий принцип, оскільки детальніше права доступу розбиратимемо в третій частині серії.
Команда umask показує маску прав, які виключаються під час створення нових об’єктів.
umask
Типовий результат для багатьох систем:
0022
Для звичайного файлу, який програма створює із запитаними правами 666, маска 022 дає результат 644. Це означає, що власник може читати та змінювати файл, а група й інші користувачі отримують право читання.
Для каталогу із запитаними правами 777 та сама маска зазвичай дає 755. Власник зможе переглядати, створювати й видаляти записи відповідно до прав каталогу, а інші користувачі матимуть обмеженіші можливості.
Важливо, що umask працює як побітова маска виключення, а не звичайне арифметичне віднімання. До того ж вона не може додати права, яких програма спочатку не запитувала.
Щоб перевірити поведінку, можна створити тестовий файл і каталог:
umask 022 touch test.txt mkdir testdir ls -ld test.txt testdir
Якщо потрібно обмежити доступ до нових файлів, можна встановити суворішу маску:
umask 077
За типових умов після цього нові звичайні файли матимуть права 600, а каталоги – 700. Це може бути корисно під час роботи з персональними конфігураціями, ключами або іншими даними, до яких не повинен мати доступ сторонній користувач.
Водночас зміна umask у поточній оболонці зазвичай впливає лише на неї та дочірні процеси. Для постійних налаштувань потрібно враховувати конфігурацію оболонки, PAM, systemd та інші механізми запуску.
Після створення користувача його параметри можуть змінюватися. Наприклад, співробітнику потрібно надати доступ до нового проєкту, змінити оболонку, перейменувати обліковий запис або обмежити термін його дії. Для таких операцій використовується usermod. Це одна з головних команд адміністрування локальних користувачів Linux.
Припустімо, потрібно змінити оболонку користувача deployer на Zsh:
sudo usermod -s /bin/zsh deployer
Звісно, перед цим необхідно переконатися, що відповідна оболонка встановлена й доступна в системі.
Список дозволених оболонок можна переглянути через:
cat /etc/shells
Користувач також може змінювати свою оболонку за допомогою chsh, якщо це дозволяє конфігурація системи.
Для перейменування облікового запису використовується параметр -l:
sudo usermod -l deploy-admin deployer
Він змінює ім’я користувача, але не обов’язково перейменовує домашній каталог. Якщо потрібно також перемістити домашні файли, використовується окрема операція:
sudo usermod -d /home/deploy-admin -m deploy-admin
Такі зміни краще виконувати, коли користувач не має активних сеансів і запущених процесів, що залежать від старих шляхів. Також потрібно перевірити конфігурації служб, заплановані завдання та інші компоненти, де старе ім’я могло бути зазначене явно. Ще один важливий сценарій – тимчасове блокування доступу.
Для блокування парольної автентифікації можна виконати:
sudo passwd -l deploy-admin
Перевірити статус:
sudo passwd -S deploy-admin
А для повернення можливості парольної автентифікації, якщо пароль придатний до використання:
sudo passwd -u deploy-admin
Однак тут є нюанс, який часто стає причиною помилок у безпеці. Блокування пароля не завжди означає повне блокування облікового запису. Якщо користувач входить через SSH-ключ або інший дозволений метод автентифікації, доступ може залишатися можливим.
Тому під час звільнення співробітника або реагування на компрометацію потрібно перевіряти всі доступні способи входу. Це можуть бути SSH-ключі, активні сесії, сертифікати, токени, централізована автентифікація або доступ через автоматизовані системи.
Для локального облікового запису можна встановити дату завершення його дії:
sudo usermod --expiredate 1 deploy-admin
Такий підхід позначає обліковий запис як прострочений у механізмах, які враховують цей параметр. Але для повного відкликання доступу в корпоративній інфраструктурі також необхідно перевірити зовнішні системи автентифікації, ключі й активні процеси.
Коли обліковий запис більше не потрібен, його можна видалити через userdel. Однак у Linux видалення користувача та видалення всіх належних йому файлів не є тотожними операціями.
Наприклад:
sudo userdel deploy-admin
Зазвичай ця команда видаляє локальні записи облікового запису, але не очищає всі його файли у файловій системі.
Якщо потрібно видалити також домашній каталог і локальну поштову скриньку, використовується параметр -r:
sudo userdel -r deploy-admin
Перед такими діями потрібно перевірити, чи не залишилися важливі дані в домашньому каталозі, чи не використовуються файли користувача іншими службами та чи не працюють від його імені активні процеси.
Особлива проблема виникає з файлами, які розташовані за межами домашнього каталогу. Наприклад, користувач міг створювати файли в /srv, /opt або спільних каталогах застосунків. Після видалення акаунта ці об’єкти можуть залишитися з числовим UID, якому більше не відповідає жоден локально відомий користувач.
Для пошуку таких об’єктів існує параметр -nouser команди find:
sudo find /srv -nouser -ls
Аналогічно -nogroup дозволяє знайти файли, для яких система не може визначити групу.
sudo find /srv -nogroup -ls
Ці перевірки корисні після видалення облікових записів, але проводити їх потрібно з урахуванням зовнішніх джерел користувачів і особливостей файлової системи.
Ще одна небезпека пов’язана з повторним використанням UID. Якщо через певний час новому користувачу буде призначено ідентифікатор видаленого акаунта, він потенційно зможе отримати доступ до залишених файлів, якщо інші механізми не обмежують такий доступ.
Тому коректне видалення користувача передбачає не лише запуск userdel, а й перевірку його файлів, повноважень, активних сесій і залежностей у системі.
Для керування локальними групами Linux надає окремий набір утиліт: groupadd, groupmod і groupdel.
Найпростіша операція – створення нової групи. Наприклад, якщо кільком інженерам потрібен спільний доступ до проєкту, можна створити групу developers:
sudo groupadd developers
За потреби адміністратор може самостійно призначити GID:
sudo groupadd -g 5000 infrastructure
Зазвичай краще дозволяти системі автоматично вибирати вільні ідентифікатори, якщо немає конкретної причини використовувати фіксований GID.
Для зміни назви групи застосовується groupmod -n:
sudo groupmod -n backend developers
У цьому випадку група developers отримає назву backend, а її числовий GID залишиться незмінним.
Для видалення непотрібної групи використовується:
sudo groupdel backend
Проте групу, яка є основною для наявного користувача, звичайна утиліта може не дозволити видалити. Також перед видаленням потрібно перевірити файли, каталоги та служби, які залежать від її GID.
Для додавання існуючого користувача до додаткової групи зазвичай використовують usermod -aG.
Наприклад:
sudo usermod -aG infrastructure deployer
Тут параметр -G визначає список додаткових груп, а -a означає додавання до вже наявного членства. Це дуже важлива відмінність. Якщо виконати usermod -G без -a, список додаткових груп користувача буде замінений новим. У результаті він може втратити доступ до ресурсів, якими користувався раніше, включно з адміністративними повноваженнями.
Якщо потрібно додати користувача одразу до кількох груп, їхні назви перелічуються через кому:
sudo usermod -aG infrastructure,developers deployer
ъПеревірити результат можна командами:
id deployer groups deployer
Потрібно враховувати, що зміни членства не обов’язково одразу впливають на вже запущені процеси. Зазвичай користувачу потрібно повторно ввійти до системи, щоб нові групи застосувалися до його сеансу.
Для запуску оболонки з іншою активною групою можна використати:
newgrp infrastructure
Однак це не тотожне повному оновленню всього існуючого сеансу, тому після зміни привілеїв надійніше перевіряти їх у новому вході.
Розглянемо типовий сценарій. На сервері є каталог /srv/project, у якому зберігаються файли застосунку. Кілька розробників повинні мати до нього доступ, але іншим користувачам ці файли не потрібні. Для цього можна створити групу project-team, призначити її каталогу та надати відповідні групові права.
sudo groupadd project-team sudo mkdir -p /srv/project sudo chgrp project-team /srv/project sudo chmod 2770 /srv/project
Значення 2770 означає, що власник і група мають стандартні повні права на каталог, інші користувачі не мають доступу, а біт SGID допомагає успадковувати групу для нових об’єктів, створених усередині.
Далі потрібних користувачів можна додати до групи:
sudo usermod -aG project-team deployer sudo usermod -aG project-team maria
Після оновлення їхніх сеансів користувачі зможуть працювати зі спільним каталогом відповідно до налаштованих прав.
Водночас SGID сам по собі не гарантує, що кожен новий файл буде доступний для запису всім учасникам групи. На це впливають umask, права створення файлів і можливі ACL. Тому для повноцінної спільної роботи іноді потрібно додатково налаштовувати стандартні ACL. Детальніше ці механізми розглянемо в третій частині серії, присвяченій правам доступу.
Під час щоденної роботи із сервером регулярно виникають завдання, які звичайний користувач не може виконати без додаткових повноважень. Наприклад, встановлення пакетів, керування системними службами або редагування конфігурацій у /etc.
У Linux для таких операцій часто використовуються su і sudo. Обидва інструменти дозволяють працювати від імені іншого користувача, але принципи їх використання відрізняються.
Команда su (substitute user) дозволяє запустити оболонку або команду від імені іншого облікового запису.
Наприклад:
su - deployer
У типовій конфігурації система попросить пароль цільового користувача, після чого запустить його оболонку входу.
Якщо потрібно перейти до root:
su -
Комбінація з дефісом створює середовище входу цільового користувача. Це означає, що змінюються відповідні змінні середовища, домашній каталог, робоче середовище та запускаються передбачені конфігураційні файли оболонки.
На відміну від цього, звичайне su може зберігати частину поточного середовища, хоча точна поведінка залежить від реалізації та налаштувань системи.
Команда su зручна, коли потрібно тривалий час працювати від імені іншого користувача, наприклад для перевірки його середовища або діагностики проблем з обліковим записом. В Ubuntu прямий парольний вхід під root за замовчуванням зазвичай вимкнений, тому адміністратори частіше користуються sudo.
Команда sudo дозволяє виконувати окремі операції від імені root або іншого користувача відповідно до встановленої політики доступу.
Наприклад, для оновлення списку пакетів в Ubuntu чи Debian використовується:
sudo apt update
Така команда запускає лише зазначену операцію з потрібними привілеями, не вимагаючи постійної роботи в адміністративній оболонці.
Для виконання команди від імені іншого користувача використовується параметр -u:
sudo -u www-data id
Це може знадобитися для перевірки середовища системної служби або того, які ідентифікатори отримує процес під час запуску.
Щоб переглянути власні дозволи sudo, можна виконати:
sudo -l
Результат залежатиме від поточної політики та покаже команди, які дозволено запускати.
За потреби можна відкрити адміністративну оболонку:
sudo -i
Але залишатися в такій оболонці без потреби не варто. У ній звичайна помилка в команді може мати значно серйозніші наслідки, оскільки наступні операції виконуватимуться з підвищеними привілеями.
Для DevSecOps перевага sudo полягає в можливості делегувати лише визначені дії. Наприклад, користувачу можна дозволити перезапуск конкретної служби, не надаючи повний адміністративний доступ.
Крім того, sudo може реєструвати виконувані команди та іншу інформацію про сесії відповідно до конфігурації. Це корисно для аудиту, хоча стандартне журналювання не означає повного запису всіх дій, які були виконані всередині запущеної оболонки або програми.
Правила використання sudo традиційно визначаються у файлі /etc/sudoers та додаткових файлах, підключених із /etc/sudoers.d/.
У цих правилах адміністратор може вказати, які користувачі та групи мають право виконувати певні команди, від чийого імені вони запускаються та чи потрібно проходити автентифікацію. Однак редагувати цей файл звичайним текстовим редактором небезпечно. Помилка в синтаксисі може призвести до втрати можливості використовувати sudo.
Для безпечнішого редагування існує visudo:
sudo visudo
У типовій конфігурації Ubuntu можна зустріти правило:
%sudo ALL=(ALL:ALL) ALL
Символ % позначає групу, тому правило стосується учасників групи sudo. Воно дозволяє їм виконувати команди від імені інших користувачів і груп у межах заданої політики.
Для окремих служб можна створювати вузькі правила. Наприклад, якщо спеціальному користувачу потрібно лише перезапускати Nginx, можна передбачити дозвіл на конкретну команду.
Важливо, щоб такі правила враховували повний шлях до виконуваного файлу, можливі аргументи та поведінку самої програми. Якщо команда дозволяє запускати довільні підпроцеси або змінювати системні файли, навіть формально обмежене правило може фактично надати значно ширші привілеї.
Особливо обережно слід ставитися до використання NOPASSWD, яке дозволяє запускати визначені команди без повторного введення пароля. Цей механізм може бути корисним для автоматизації, але неправильно налаштовані правила створюють додаткові можливості для зловживань.
Для організації окремих політик зручніше використовувати файли в /etc/sudoers.d/. Наприклад, конфігурацію для конкретного службового акаунта можна редагувати через:
sudo visudo -f /etc/sudoers.d/deployer
Після внесення змін бажано перевірити синтаксис усієї конфігурації:
sudo visudo -c
У виробничому середовищі також необхідно переконатися, що доступ до файлів політики обмежений і що зміни не відкривають небажаних шляхів підвищення привілеїв.
Одна з найпоширеніших адміністративних помилок – надання користувачам надмірних повноважень лише для того, щоб швидко розв’язати проблему з доступом. Наприклад, якщо інженер не може взаємодіяти з Docker daemon, додавання його до групи docker може прибрати помилку. Але в стандартній rootful-конфігурації Docker такий доступ дозволяє виконувати високопривілейовані операції, включно зі створенням контейнерів, які отримують доступ до ресурсів хоста.
Аналогічна проблема виникає, коли для автоматизованого завдання створюють окремого користувача, але дозволяють йому запускати через sudo довільні команди від імені root. З технічного погляду це може виглядати зручно, особливо для CI/CD. Проте якщо відповідний сервіс або його секрети будуть скомпрометовані, зловмисник потенційно зможе використати надані привілеї для подальшого доступу до системи.
Тому в Linux важливо дотримуватися принципу найменших привілеїв. Користувач, процес або служба повинні отримувати лише ті дозволи, які необхідні для конкретного завдання. Для адміністратора це означає регулярну перевірку членства в групах, обмеження доступу до службових облікових записів, контроль конфігурації sudo та своєчасне відкликання непотрібних прав.
Додатково варто перевіряти користувачів, які давно не використовуються, невідомі SSH-ключі, неконтрольовані службові облікові записи та права доступу до конфіденційних каталогів. Окрему увагу потрібно приділяти автоматизації. Скрипти розгортання, системи CI/CD та агенти моніторингу часто працюють без постійної участі людини. Якщо їм надано надлишкові привілеї, наслідки помилки або компрометації можуть бути значно серйознішими.
Щоб закріпити отримані знання, розглянемо типовий сценарій роботи на тестовому сервері Ubuntu або Debian. Припустімо, потрібно створити окремого користувача для розгортання застосунку та організувати спільну групу для роботи з його файлами.
Наведені команди змінюють локальні облікові записи та системні каталоги, тому виконувати їх слід лише на власній тестовій машині або у віртуальному середовищі.
Спочатку створимо групу:
sudo groupadd project-team
Тепер створимо нового користувача lab-deployer із домашнім каталогом та оболонкою Bash:
sudo useradd -m -s /bin/bash lab-deployer
Далі додамо його до створеної групи:
sudo usermod -aG project-team lab-deployer
Перевіримо отримані ідентифікатори:
id lab-deployer getent group project-team
У результаті lab-deployer повинен відображатися серед додаткових учасників групи.
Тепер створимо каталог для навчального застосунку:
sudo mkdir -p /srv/lab-project sudo chgrp project-team /srv/lab-project sudo chmod 2770 /srv/lab-project
Це дозволить організувати груповий доступ до каталогу, а також допоможе зберігати групу project-team для нових об’єктів усередині нього.
Для більш передбачуваної спільної роботи необхідно додатково враховувати права створюваних файлів і значення umask.
Тепер перевіримо, чи може користувач створити файл у каталозі:
sudo -u lab-deployer touch /srv/lab-project/test.txt
Якщо налаштування коректні, команда завершиться без помилки.
Перевіримо власника, групу та права доступу:
ls -ld /srv/lab-project ls -l /srv/lab-project/test.txt
У цьому прикладі можна побачити, як система пов’язує обліковий запис, групу та файлові дозволи. Саме такі принципи використовуються під час організації доступу до проєктів, каталогів застосунків та спільних робочих ресурсів.
Після завершення навчання видалимо тестові файли та обліковий запис:
sudo rm -f /srv/lab-project/test.txt sudo rmdir /srv/lab-project sudo userdel -r lab-deployer sudo groupdel project-team
Ці команди розраховані на щойно створене навчальне середовище. Перед їх виконанням переконайтеся, що в каталозі немає важливих даних, а користувач і група не використовуються іншими процесами.
🔎 Перегляд користувачів та їхніх даних
whoami– показати поточного ефективного користувача.
id– переглянути UID, GID та групи користувача.
groups– перевірити членство користувача в групах.
getent passwd– отримати записи облікових записів.
getent group– переглянути інформацію про групи.
👤 Керування обліковими записами
useradd– створити нового користувача.
usermod– змінити параметри облікового запису.
userdel– видалити користувача.
passwd– встановити, змінити або заблокувати пароль.
chage– керувати термінами дії пароля.
chsh– змінити командну оболонку користувача.
👥 Робота з групами
groupadd– створити нову групу.
groupmod– змінити назву або GID групи.
groupdel– видалити групу.
newgrp– запустити оболонку з іншою активною групою.
🔐 Права доступу та привілеї
umask– переглянути або змінити маску прав для нових файлів.
su– перемкнутися на іншого користувача.
sudo– виконати команду з дозволеними привілеями.
visudo– редагувати та перевіряти правилаsudo.
⚙️ Редагування системних облікових записів
vipw– безпечніше редагувати записи користувачів у/etc/passwd.
vigr– безпечніше редагувати записи груп у/etc/group.
Більшість команд керування обліковими записами потребують адміністративних повноважень. Перед зміною системних користувачів, груп або конфігурацій необхідно розуміти наслідки операції та перевіряти, чи не використовуються відповідні облікові записи службами.
Користувачі та групи в Linux є не просто способом організації облікових записів. Вони формують основу розмежування доступу між людьми, службами та процесами, які працюють у системі.
У другій частині серії ми розібрали UID і GID, призначення системних користувачів, структуру /etc/passwd, /etc/shadow та інших файлів облікових записів. Також розглянули створення, зміну й видалення користувачів, керування групами, налаштування стандартних прав і роботу з адміністративними привілеями через su та sudo.
Для DevOps ці знання необхідні під час налаштування серверів, розгортання застосунків і автоматизації інфраструктури. Для DevSecOps вони є основою контролю доступу та зменшення ризиків, пов’язаних із надмірними повноваженнями.
У третій частині серії «Linux для DevOps і DevSecOps» детально розглянемо права доступу до файлів і каталогів, механізми chmod та chown, біти SUID, SGID і Sticky Bit, а також ACL. Розберемо, як правильно налаштовувати дозволи й уникати помилок, які можуть поставити під загрозу безпеку Linux-сервера.
