Права доступу в Linux визначають, хто може читати, змінювати та запускати файли, працювати з каталогами й керувати системними ресурсами. Для DevOps і DevSecOps правильне налаштування дозволів є важливою частиною адміністрування серверів і захисту інфраструктури. У третій частині серії розберемо модель UGO, права rwx, числовий і символьний запис дозволів, команди chmod, chown і chgrp, а також спеціальні біти SUID, SGID, Sticky Bit та розширені списки контролю доступу ACL.
У попередніх частинах серії ми розібрали файлову систему Linux, навігацію через термінал, роботу з користувачами та групами. Тепер перейдемо до механізмів, які визначають, що саме ці користувачі можуть робити із системними ресурсами. Адже створити обліковий запис або додати його до групи недостатньо. Потрібно ще правильно налаштувати доступ до файлів, каталогів, конфігурацій і служб, щоб кожен користувач мав необхідні можливості, але не отримував зайвих привілеїв.
Це особливо важливо для серверної інфраструктури, де одночасно працюють вебсервери, бази даних, автоматизовані скрипти та облікові записи розробників. Помилка в дозволах може призвести як до банальної відмови застосунку, так і до витоку конфіденційних даних або підвищення привілеїв зловмисником. Тому в цій частині ми не просто розглянемо набір команд, а розберемо логіку роботи Linux із правами доступу та навчимося застосовувати її на практиці.
Linux є багатокористувацькою операційною системою, у якій різні користувачі та процеси можуть одночасно працювати з одними й тими самими ресурсами. Наприклад, вебсервер Nginx обслуговує файли сайту, PostgreSQL працює зі своєю базою даних, а розробник редагує вихідний код застосунку. При цьому кожен із цих компонентів повинен мати доступ лише до необхідної інформації.
Для розмежування повноважень Linux використовує систему прав доступу. Кожен звичайний файл або каталог має власника, групу та набір дозволів, які визначають доступні операції. Ця інформація зберігається в метаданих файлової системи, зокрема в inode, який містить характеристики файлового об’єкта.
Коли користувач намагається відкрити файл або змінити його вміст, система перевіряє відповідні ідентифікатори процесу, права об’єкта та інші обмеження. Якщо необхідних дозволів немає, операція зазвичай завершується помилкою Permission denied.
Переглянути стандартні права доступу можна за допомогою знайомої з першої частини команди ls:
ls -l /etc/passwd
На типовій системі результат може виглядати так:
-rw-r--r-- 1 root root 2847 Nov 2 10:30 /etc/passwd
На перший погляд це просто рядок із набором символів і чисел. Насправді він містить майже всю основну інформацію, необхідну для початкової перевірки доступу до файлу.
Перший блок -rw-r--r-- показує тип об’єкта та його дозволи. Далі йде кількість жорстких посилань, ім’я власника, група-власник, розмір, час останньої зміни вмісту та назва файлу.
Особливу увагу потрібно звертати саме на перший блок. Він показує, чому один користувач може змінювати файл, інший лише читати його, а третій взагалі не має доступу.
Стандартна модель прав доступу Linux називається UGO, що розшифровується як User, Group та Others. Вона розділяє користувачів на три категорії відносно конкретного файлу або каталогу.
User (u) – власник об’єкта, тобто користувач, чий UID зазначений у його метаданих.
Group (g) – група-власник, учасники якої можуть отримувати спільні дозволи.
Others (o) – усі інші користувачі, які не отримують доступ через категорію власника або відповідну групу.
Для кожної категорії встановлюється окремий набір прав. Завдяки цьому можна дозволити власнику повністю керувати файлом, учасникам певної групи лише читати його, а всім іншим заборонити доступ.
Розглянемо приклад:
-rwxr-x---
Перший символ - означає, що перед нами звичайний файл. Наступні дев’ять символів розподіляються на три групи:
- rwx r-x --- │ │ │ │ │ └── Others │ └─────── Group └──────────── User
Власник має права rwx, тобто може читати, змінювати та виконувати файл. Група має права r-x, які дозволяють читання й виконання без запису. Решта користувачів не мають жодного стандартного дозволу.
Крім звичайних файлів, у Linux існують каталоги, символічні посилання, сокети, пристрої та інші типи файлових об’єктів. Визначити їх можна за першим символом у виведенні ls -l.
| Символ | Тип об’єкта |
- |
Звичайний файл |
d |
Каталог |
l |
Символічне посилання |
b |
Блоковий пристрій |
c |
Символьний пристрій |
p |
Іменований канал |
s |
Unix-сокет |
Наприклад, якщо права починаються з d, перед нами каталог. Якщо з l, це символічне посилання. Для останнього стандартні дозволи, які показує ls, зазвичай не визначають доступ до цільового файлу: система перевіряє сам об’єкт, на який веде посилання, та дозволи на проходження відповідних каталогів.
Важливо пам’ятати, що стандартна модель UGO передбачає одного власника та одну групу-власника для кожного об’єкта. Якщо необхідно надати окремі дозволи багатьом користувачам і групам, можуть знадобитися ACL, які ми розглянемо далі.
У кожній із трьох категорій UGO використовуються однакові позначення: r, w і x. Вони відповідають операціям читання, запису та виконання.
Для звичайного файлу все досить просто. Право r дозволяє читати його вміст, w дозволяє змінювати дані, а x дає можливість запускати файл як виконувану програму, якщо його формат та інші умови це дозволяють.
Наприклад, конфігураційний файл застосунку може мати права rw-r-----. Це означає, що власник може читати та редагувати конфігурацію, члени відповідної групи можуть лише читати її, а інші користувачі не отримують доступу.
Однак для каталогів ті самі символи мають інше практичне значення, і саме тут часто виникають помилки.
Право r для каталогу дозволяє читати список його записів, w разом із необхідним правом проходження дозволяє створювати, перейменовувати та видаляти записи, а x відповідає за проходження каталогу й звернення до об’єктів усередині нього за відомими назвами.
Уявімо, що користувач має доступ до читання каталогу, але не має права x. Він може отримати список назв файлів, однак не зможе нормально звернутися до них через цей каталог. Якщо ж право x є, але r немає, користувач за певних умов може відкрити файл за відомою назвою, хоча отримати повний список вмісту каталогу не зможе.
Це пояснює ситуації, коли файл має права на читання для всіх, але відкрити його все одно неможливо. Проблема може бути не в самому файлі, а в одному з батьківських каталогів, через який потрібно пройти.
Перевірити права на всіх компонентах шляху допомагає команда namei:
namei -l /var/www/html/index.html
Вона покаже окремі компоненти шляху разом із дозволами, власниками та групами. Це особливо корисно під час діагностики вебсерверів, коли Nginx або Apache не може прочитати файл через відсутність права проходження одного з каталогів.
Ще один нюанс: видалення файлу визначається насамперед правами на каталог, у якому він розташований, а не правом w самого файлу. Тому користувач із правом запису до каталогу може за певних умов видалити файл, навіть якщо не має права змінювати його вміст. На поведінку також впливають Sticky Bit, ACL та інші обмеження файлової системи.
У Linux права можна задавати двома основними способами: числовим та символьним. Обидва використовуються в реальному адмініструванні, але підходять для дещо різних ситуацій.
Числовий формат базується на вісімковій системі числення. Кожне стандартне право має власне значення:
| Право | Значення |
|---|---|
r |
4 |
w |
2 |
x |
1 |
- |
0 |
Щоб визначити числовий запис, потрібно скласти значення дозволених операцій для кожної категорії. Наприклад, rwx дорівнює 7, оскільки 4 + 2 + 1 = 7. Комбінація rw- відповідає 6, а r-x дорівнює 5.
Загальний набір прав записується трьома цифрами, кожна з яких відповідає власнику, групі та іншим користувачам.
755 = rwx r-x r-x 644 = rw- r-- r-- 600 = rw- --- --- 700 = rwx --- --- 750 = rwx r-x --- 640 = rw- r-- ---
Наприклад, права 644 часто використовуються для звичайних текстових файлів, які можуть читати всі користувачі, але змінювати лише власник. Для виконуваних програм і відкритих для проходження каталогів нерідко застосовують 755. Водночас приватним SSH-ключам зазвичай потрібні значно суворіші права, наприклад 600.
Особливу обережність слід проявляти зі значенням 777. Воно надає всім трьом категоріям повний набір стандартних дозволів. Для каталогу це може означати, що інші користувачі здатні створювати й видаляти записи, якщо додаткові механізми не обмежують операції. Для звичайного файлу такі права дозволяють будь-якому користувачу змінювати його вміст.
На сервері з кількома обліковими записами це може створити серйозну проблему безпеки, особливо якщо доступним для запису стає конфігураційний файл або скрипт, який пізніше запускається з адміністративними привілеями.
Символьний формат дозволяє змінювати окремі дозволи, не перераховуючи весь набір прав. Для нього використовуються позначення u, g, o та a, де остання літера означає всі категорії. Символ + додає право, - прибирає його, а = встановлює точний набір дозволів для зазначеної категорії.
Наприклад:
chmod u+x script.sh chmod g-w config.ini chmod o-rwx private.txt chmod u=rw,g=r,o= report.txt
Перша команда додає власнику право виконання скрипту. Друга забирає можливість запису в учасників групи, третя повністю прибирає стандартні дозволи для інших користувачів, а четверта явно визначає доступ для всіх трьох категорій.
Числовий формат зручніший, коли потрібно встановити конкретний підсумковий стан. Символьний краще використовувати, коли необхідно змінити лише один або кілька дозволів, зберігши решту.
Команда chmod (change mode) використовується для зміни прав доступу до файлових об’єктів. Вона підтримує числовий і символьний формати, а також рекурсивну обробку каталогів.
Для початку створимо невелике тестове середовище, у якому можна безпечно перевірити роботу команди:
mkdir -p ~/linux-permissions cd ~/linux-permissions touch config.txt printf '#!/bin/sh\necho "Hello, Linux!"\n' > script.sh ls -l
Тепер встановимо для конфігураційного файлу права 640, а для скрипту додамо власнику право виконання:
chmod 640 config.txt chmod u+x script.sh ls -l
У результаті config.txt буде доступний для читання та запису власнику, лише для читання групі й недоступний іншим користувачам. Скрипт отримає дозвіл на виконання від імені власника, хоча його фактичний запуск також залежатиме від формату файлу, файлової системи та інших перевірок.
Для застосування прав до всього дерева каталогів використовується параметр -R. Наприклад:
chmod -R 750 ~/linux-permissions
Але тут є важливий нюанс. Команда встановить 750 абсолютно всім об’єктам усередині каталогу, включно зі звичайними текстовими файлами. У результаті файли отримають право виконання, яке їм може бути зовсім не потрібне.
Це поширена помилка під час налаштування вебсерверів. Адміністратор хоче надати доступ до всіх каталогів сайту та виконує рекурсивний chmod 755, не враховуючи різницю між файлами й директоріями.
Натомість дозволи можна встановлювати окремо, використовуючи знайому нам команду find:
find ~/linux-permissions -type d -exec chmod 755 {} +
find ~/linux-permissions -type f -exec chmod 644 {} +
Перший рядок встановлює 755 лише для каталогів, а другий 644 для звичайних файлів. Це підходить для навчальних файлів, але у реальному проєкті потрібно окремо врахувати виконувані скрипти, приватні конфігурації та інші об’єкти, яким необхідні спеціальні права.
Ще один корисний механізм – велика літера X у символьному форматі. На відміну від x, вона додає право виконання лише каталогам і файлам, для яких хоча б одна категорія вже має відповідний дозвіл.
chmod -R a+X ~/linux-permissions
Такий підхід допомагає додати необхідне право проходження каталогів, не перетворюючи всі звичайні документи на виконувані файли.
Водночас рекурсивні операції з правами потрібно виконувати обережно. Перед застосуванням до системних директорій варто перевірити їхній поточний стан, структуру та вимоги служб, які працюють із відповідними файлами.
Окрім стандартних дозволів, для контролю доступу має значення те, кому належить файл і яка група призначена його власником. Ці параметри можна змінювати за допомогою chown та chgrp.
Команда chown (change owner) дозволяє змінити власника файлу, групу або обидва значення одночасно. Команда chgrp призначена для зміни групи-власника.
Розглянемо приклади:
sudo chown deployer config.txt sudo chgrp developers config.txt sudo chown deployer:developers config.txt
Перша команда змінює власника на deployer, друга призначає групу developers, а третя змінює обидва параметри за одну операцію. Для виконання прикладів відповідні користувач і група повинні існувати в системі.
Для рекурсивної зміни власника та групи використовується параметр -R:
sudo chown -R deployer:developers /srv/project
Це може бути корисно під час перенесення проєкту або виправлення власників після розгортання застосунку. Однак рекурсивне призначення власника потрібно виконувати лише після перевірки структури каталогу, оскільки воно може змінити права на конфіденційні файли, службові каталоги та інші компоненти.
Звичайний користувач у Linux, як правило, не може передати власність на файл довільному іншому користувачу. Для цього потрібні відповідні адміністративні повноваження. Водночас власник може змінювати групу свого файлу на одну з груп, до яких належить, якщо це дозволено налаштуваннями системи.
Окремо варто враховувати практику розгортання вебзастосунків. Призначати всі файли сайту власністю користувача вебсервера не завжди правильно. Якщо вебсерверу потрібно лише читати статичні файли, краще не надавати йому можливість змінювати весь код застосунку.
У випадку компрометації вебпроцесу надмірні права на запис можуть дозволити зловмиснику змінювати файли сайту або створювати нові небезпечні скрипти. Тому власника, групу та дозволи потрібно визначати залежно від реальних потреб процесів, а не просто надавати всім максимально широкий доступ.
Щоб правильно працювати з файловими дозволами, важливо розуміти не лише їхній запис, а й те, як система приймає рішення про доступ. Саме нерозуміння цього механізму часто призводить до ситуацій, коли користувач бачить помилку Permission denied, хоча на перший погляд потрібні права встановлені.
Кожен процес Linux має кілька ідентифікаторів користувача. Серед них Real UID (RUID), Effective UID (EUID), Saved UID і Filesystem UID (FSUID). Вони використовуються для різних аспектів ідентифікації та керування привілеями.
Real UID зазвичай позначає користувача, від імені якого було запущено процес. Effective UID визначає ефективні повноваження для багатьох операцій, а FSUID використовується під час перевірок доступу до файлової системи. У звичайних процесах ці значення часто збігаються, але для програм із підвищеними привілеями можуть відрізнятися.
Переглянути UID поточного процесу можна так:
grep '^Uid:' /proc/self/status
Типовий результат:
Uid: 1000 1000 1000 1000
Чотири значення відображають реальний, ефективний, збережений та файловий UID.
Коли процес намагається отримати доступ до файлу, Linux перевіряє його ідентифікатори, групи та дозволи об’єкта. Якщо розглядати звичайну модель UGO без додаткових ACL і спеціальних механізмів, логіка приблизно така: якщо користувач є власником файлу, застосовуються дозволи власника; якщо він не власник, але належить до групи-власника, перевіряються групові дозволи; в інших випадках застосовуються права Others.
Важливий момент: права цих трьох категорій не додаються одне до одного.
Припустімо, файл належить користувачу ivan, який одночасно входить до групи developers. При цьому власнику не надано жодного стандартного дозволу, а групі дозволено читання:
----r----- 1 ivan developers 128 Nov 2 10:30 secret.txt
Може здатися, що ivan повинен мати доступ завдяки членству в developers. Але якщо процес працює від імені власника, у стандартній перевірці UGO застосовуються саме права власника, тобто ---. Групові права не компенсують їхню відсутність.
Виправити ситуацію можна, додавши власнику відповідний дозвіл:
chmod u+r secret.txt
Цей приклад демонструє принцип перевірки, хоча подібне поєднання дозволів рідко використовується навмисно.
Окремо слід враховувати root. Процеси з відповідними привілеями, зокрема capabilities CAP_DAC_OVERRIDE і CAP_DAC_READ_SEARCH, можуть обходити значну частину стандартних файлових перевірок. Однак це не означає, що вони повністю позбавлені обмежень.
Наприклад, для прямого виконання звичайного файлу Linux вимагає наявності хоча б одного біта виконання. Якщо жодного x немає, навіть привілейований процес не зможе просто запустити його через execve. Водночас інтерпретатор може прочитати й виконати текст скрипту іншим способом, якщо має відповідні права.
Крім UGO, на результат впливають ACL, політики SELinux або AppArmor, параметри монтування, атрибути файлової системи та інші механізми. Саме тому в складних випадках недостатньо перевірити лише chmod і власника.
Окрім трьох стандартних дозволів rwx, у Linux існують спеціальні біти, які змінюють поведінку виконуваних файлів і каталогів. Найважливіші з них – SUID, SGID та Sticky Bit. Ці механізми використовуються для керування привілеями програм, організації спільної роботи й захисту файлів у загальнодоступних каталогах. Водночас неправильне налаштування може створити додаткові ризики для безпеки.
SUID (Set User ID) – спеціальний біт, який на підтримуваних виконуваних файлах дозволяє програмі отримувати ефективний UID власника файлу під час запуску.
Один із класичних прикладів – утиліта passwd. Звичайний користувач повинен мати можливість змінити власний пароль, але не має прямого доступу на запис до /etc/shadow, де зберігаються хеші паролів. У типовій конфігурації для виконання необхідних операцій використовується привілейована програма, яка перевіряє дозволені дії та змінює відповідні записи.
Перевіримо дозволи утиліти:
ls -l /usr/bin/passwd
На багатьох системах можна побачити щось подібне:
-rwsr-xr-x 1 root root 68248 Nov 2 10:30 /usr/bin/passwd
Літера s замість звичайного x у блоці власника означає, що встановлено SUID і право виконання. У числовому форматі SUID представлений значенням 4000. Для його налаштування використовуються chmod u+s або чотиризначний числовий запис, наприклад 4755.
Проте встановлювати SUID на довільні програми, особливо на скрипти або інструменти, які дозволяють запускати команди, не варто. SUID на непридатному для цього виконуваному файлі може створити небезпечний шлях підвищення привілеїв. У Linux SUID для звичайних інтерпретованих скриптів загалом ігнорується ядром. Для виконуваних програм його поведінка також залежить від обмежень на кшталт no_new_privs, параметра монтування nosuid і механізмів трасування. Для DevSecOps важливо знати, як знаходити файли з SUID та перевіряти, чи відповідає їхній перелік очікуваній конфігурації системи.
sudo find /usr /bin /sbin -type f -perm -4000 -print 2>/dev/null
Наявність SUID на стандартній системній утиліті не обов’язково є проблемою. Однак несподівана поява такого біта на новому або зміненому виконуваному файлі є приводом перевірити його походження, призначення та цілісність.
SGID (Set Group ID) працює по-різному для виконуваних файлів і каталогів. Для підтримуваних виконуваних файлів він дозволяє процесу отримувати ефективний GID групи-власника. Проте значно частіше цей механізм використовують на каталогах, де SGID впливає на групову належність нових файлів і підкаталогів.
Припустімо, кілька розробників працюють над одним проєктом. У кожного власна основна група, але всі вони входять до спільної групи developers. Без спеціальних налаштувань нові файли можуть отримувати особисті групи користувачів, що ускладнює спільну роботу. Якщо на каталозі встановити SGID, створені всередині об’єкти за типової поведінки Linux успадковуватимуть його групу-власника.
sudo chgrp developers /srv/project sudo chmod g+s /srv/project ls -ld /srv/project
У результаті в груповому блоці дозволів може з’явитися літера s:
drwxr-sr-x 2 root developers 4096 Nov 2 10:30 /srv/project
Числове значення SGID – 2000. Тому його можна встановити через чотиризначний запис, наприклад 2755 або 2770, залежно від потрібних стандартних дозволів. Водночас потрібно розуміти, що SGID забезпечує успадкування групи, але не гарантує права запису для всіх її учасників. Для цього необхідно додатково врахувати стандартні дозволи нових файлів, umask та можливі ACL.
Sticky Bit використовується насамперед для каталогів, у яких кілька користувачів мають право створювати файли, але не повинні безконтрольно видаляти або перейменовувати чужі об’єкти. Класичний приклад – каталог /tmp, який використовується для тимчасових файлів різними програмами та користувачами.
Перевіримо його права:
ls -ld /tmp
На типовій Linux-системі результат має такий вигляд:
drwxrwxrwt 18 root root 4096 Nov 2 10:30 /tmp
Літера t наприкінці означає встановлений Sticky Bit разом із правом проходження для Others. Завдяки цьому звичайний користувач, навіть маючи право запису до спільного каталогу, не може просто видалити чужий файл. Зазвичай видалення або перейменування дозволяється власнику файлу, власнику каталогу або процесу з відповідними привілеями, за умови виконання інших перевірок доступу.
Sticky Bit можна встановити командою:
sudo chmod +t /srv/shared
Або числовим способом:
sudo chmod 1777 /srv/shared
Остання команда надає широкі стандартні дозволи всім користувачам, тому застосовувати її варто лише для каталогів, де така поведінка справді потрібна. Для звичайних робочих директорій безпечніше обмежувати доступ відповідними групами та ACL.
Числові значення спеціальних бітів:
| Біт | Значення | Основне призначення |
|---|---|---|
| SUID | 4000 |
Ефективний UID власника під час виконання |
| SGID | 2000 |
Групові привілеї або успадкування групи каталогу |
| Sticky Bit | 1000 |
Обмеження видалення й перейменування у спільному каталозі |
Спеціальні біти можуть комбінуватися між собою, але в більшості адміністративних завдань використовуються окремо, відповідно до призначення ресурсу.
Стандартна модель UGO досить проста, але її можливостей не завжди вистачає для реальних сценаріїв. Наприклад, файл належить користувачу admin, а доступ до нього потрібно надати ще двом людям: maria повинна мати право читання та запису, тоді як sergei – лише читання.
За допомогою базових дозволів UGO реалізувати таке розмежування без додаткової організації груп складно. Для більш гнучкого керування доступом використовуються ACL (Access Control Lists), або списки контролю доступу.
POSIX ACL дозволяють призначати окремі дозволи конкретним користувачам і групам, не змінюючи основного власника файлу. Це корисно для спільних каталогів, проєктних файлів, резервних копій та інших ресурсів, які використовують кілька команд.
Для роботи з ACL у Linux зазвичай використовуються утиліти getfacl і setfacl. У Debian та Ubuntu вони можуть надаватися пакетом acl:
sudo apt install acl
Припустімо, у нас є файл report.txt. Переглянути його поточні ACL можна командою:
getfacl report.txt
Якщо додаткові записи не налаштовані, результат відображатиме стандартні дозволи власника, групи та інших користувачів.
Для надання користувачу maria права читання й запису виконаємо:
setfacl -m u:maria:rw report.txt
А щоб надати користувачу sergei лише читання:
setfacl -m u:sergei:r report.txt
Після цього переглянемо список:
getfacl report.txt
Результат може містити такі записи:
user::rw- user:maria:rw- user:sergei:r-- group::r-- mask::rw- other::---
Тепер файл має окремі дозволи для двох конкретних користувачів. При цьому основний власник залишається незмінним. Коли на файлі налаштовано розширені ACL, у виведенні ls -l зазвичай з’являється символ + після стандартного набору прав.
Для видалення окремого запису використовується setfacl -x:
setfacl -x u:sergei report.txt
А для видалення розширених записів ACL:
setfacl -b report.txt
Під час роботи з ACL важливо розуміти значення маски mask. Вона обмежує ефективні дозволи для іменованих користувачів, груп і групи-власника, але не для власника файлу та категорії Others. Наприклад, якщо користувачу в ACL надано rwx, але маска дозволяє лише r-x, ефективного права запису він не матиме.
Переглянути маску можна через getfacl, а змінити її так:
setfacl -m m::rx report.txt
Це пояснює ситуації, коли ACL на перший погляд містить необхідний дозвіл, але операція все одно не виконується.
Ще одна важлива можливість ACL – автоматичне успадкування дозволів новими файлами та каталогами. Уявімо спільну директорію, де постійно створюються нові файли. Якщо налаштувати ACL лише для самого каталогу, ці правила не обов’язково застосовуватимуться до нових об’єктів. Для цього використовуються default ACL, які визначають набір дозволів, що успадковується під час створення об’єктів усередині каталогу.
Наприклад, щоб налаштувати права для групи developers на існуючому каталозі та визначити стандартні ACL для майбутніх об’єктів, можна виконати:
sudo setfacl -m g:developers:rwx /srv/project sudo setfacl -d -m g:developers:rwx /srv/project
Перший рядок призначає групові дозволи самому каталогу. Другий додає ACL за замовчуванням, які використовуватимуться для нових об’єктів усередині нього. Потрібно враховувати, що фактичні права новостворених файлів також залежать від дозволів, які запитує програма. Зокрема, звичайні текстові файли не отримують автоматично право виконання лише через те, що в default ACL присутній x.
Також ці команди не змінюють уже наявні вкладені файли. Якщо потрібно налаштувати доступ для всього існуючого дерева, необхідно окремо застосувати відповідні правила рекурсивно, попередньо перевіривши структуру та вимоги до дозволів.
Ми вже коротко торкалися umask у другій частині, коли говорили про облікові записи та стандартні налаштування користувачів. Тепер розглянемо цей механізм детальніше, оскільки він безпосередньо впливає на права нових файлів і каталогів.
Команда umask показує або змінює маску дозволів, яку процес використовує під час створення нових об’єктів. Вона допомагає визначити, які стандартні права необхідно виключити з набору, запитаного програмою.
Для звичайного файлу програми часто запитують початкові права 666, тобто читання й запис для всіх трьох категорій. Для каталогів типовим початковим набором є 777, оскільки для їх проходження потрібен біт x.
Перевіримо поточну маску:
umask
Наприклад, результат:
0022
Для типових початкових дозволів така маска дає права 644 для файлів і 755 для каталогів.
Однак технічно umask працює через побітове виключення дозволів, а не звичайне арифметичне віднімання. Тому для нестандартних значень результати не завжди можна правильно визначити простою математичною різницею.
Найпоширеніші значення:
| umask | Нові файли | Нові каталоги |
|---|---|---|
022 |
644 |
755 |
027 |
640 |
750 |
077 |
600 |
700 |
Ці результати передбачають типові запитані дозволи та відсутність додаткових чинників, які змінюють поведінку створення об’єктів.
Наприклад, якщо встановити umask 077, нові файли за звичайних умов будуть доступні лише їхньому власнику:
umask 077 touch private.txt mkdir private-dir ls -ld private.txt private-dir
Це може бути корисно для файлів із конфіденційними налаштуваннями, приватними даними та іншою інформацією, доступ до якої потрібно обмежити. Для робочих серверів значення 027 часто є компромісом між безпекою та груповою взаємодією. Воно дозволяє власнику керувати файлами, зберігає обмежений доступ для групи та прибирає стандартні дозволи для Others.
Водночас універсального значення umask для всіх систем не існує. Воно залежить від призначення сервера, вимог застосунків, політик безпеки та необхідності спільної роботи. Налаштування може визначатися конфігурацією командної оболонки, PAM, параметрами створення облікового запису або конфігурацією systemd-служби.
Для поточної оболонки можна виконати:
umask 027
А в systemd unit-файлі відповідний параметр може виглядати так:
[Service] UMask=0027
Це особливо корисно для служб, які автоматично створюють файли, журнали або тимчасові дані. Правильно визначена маска допомагає зменшити ризик випадкового відкриття конфіденційної інформації.
Щоб закріпити матеріал, створимо навчальне середовище, у якому налаштуємо власника, стандартні права та ACL. Усі дії з файлами можна виконувати у власному домашньому каталозі. Для прикладів із додатковим користувачем знадобиться тестова система, де дозволено створювати локальні облікові записи.
Спочатку створимо робочу структуру:
mkdir -p ~/permissions-lab/{config,logs,shared}
cd ~/permissions-lab
touch config/app.conf
touch logs/app.log
touch shared/report.txt
Переглянемо поточні дозволи:
ls -ld config logs shared ls -l config/app.conf logs/app.log shared/report.txt
Тепер призначимо різні права залежно від призначення файлів. Конфігурацію зробимо доступною лише власнику, журнал залишимо з правом читання для групи, а каталог зі спільними файлами налаштуємо для подальшої роботи з ACL.
chmod 600 config/app.conf chmod 640 logs/app.log chmod 700 config chmod 750 logs chmod 700 shared
Перевіримо результат:
ls -ld config logs shared ls -l config/app.conf logs/app.log
На цьому етапі ми маємо кілька об’єктів із різними наборами дозволів. Конфігураційний файл доступний лише власнику, журнал має більш обмежений груповий доступ, а приватний каталог закритий для сторонніх користувачів.
Далі створимо окремий навчальний обліковий запис. Ця команда потребує адміністративних привілеїв:
sudo useradd -m -s /bin/bash labreader
Тепер через ACL надамо йому можливість проходити домашній каталог поточного користувача та шлях до тестового файлу. Для цього спочатку визначимо абсолютний шлях:
pwd
Після цього в навчальному середовищі можна виконати:
setfacl -m u:labreader:x "$HOME" setfacl -m u:labreader:rx "$HOME/permissions-lab" setfacl -m u:labreader:rx "$HOME/permissions-lab/shared" setfacl -m u:labreader:r "$HOME/permissions-lab/shared/report.txt"
Ці правила надають тестовому користувачу доступ для проходження необхідних каталогів і читання конкретного файлу, не відкриваючи весь домашній каталог для інших користувачів.
Перевіримо налаштовані ACL:
getfacl "$HOME/permissions-lab/shared/report.txt"
Тепер спробуємо прочитати файл від імені labreader:
sudo -u labreader cat "$HOME/permissions-lab/shared/report.txt"
За правильної конфігурації команда повинна виконатися без помилки. Оскільки файл порожній, у терміналі не з’явиться жодного тексту, але сама операція читання буде дозволена.
Для перевірки заборони запису спробуємо додати до файлу новий рядок:
sudo -u labreader sh -c 'echo test >> "$1"' sh "$HOME/permissions-lab/shared/report.txt"
Операція повинна завершитися помилкою доступу, оскільки для користувача labreader ми встановили лише право читання. Цей приклад показує різницю між правами на каталог, стандартними дозволами файлу та додатковими ACL. У реальній інфраструктурі ці механізми часто використовуються разом, щоб забезпечити доступ до окремих ресурсів без надмірного розширення привілеїв.
Після завершення практики можна видалити навчальний обліковий запис і створені файли:
sudo userdel -r labreader setfacl -x u:labreader "$HOME" rm -r "$HOME/permissions-lab"
Остання команда видаляє навчальний каталог. Перед виконанням переконайтеся, що його вміст більше не потрібен.
🔎 Перевірка дозволів і власників
ls -l– переглянути стандартні права, власника та групу файлу.
ls -ld– перевірити права самого каталогу.
stat– отримати детальні метадані об’єкта.
namei -l– перевірити доступ на кожному компоненті шляху.
id– переглянути UID, GID та групи користувача.
🔐 Зміна стандартних прав
chmod 644 file– встановити читання для всіх і запис лише для власника.
chmod 600 file– дозволити читання й запис лише власнику.
chmod 755 dir– дозволити власнику повний доступ, іншим читання та проходження.
chmod u+x file– додати власнику право виконання.
chmod g-w file– забрати право запису у групи.
chmod -R– рекурсивно змінити права всередині каталогу.
👤 Керування власниками та групами
chown user file– змінити власника файлу.
chown user:group file– змінити власника та групу одночасно.
chgrp group file– змінити групу-власника.
chown -R– рекурсивно змінити власника та групу.
⚙️ Спеціальні біти
chmod u+s file– встановити SUID.
chmod g+s dir– встановити SGID для каталогу.
chmod +t dir– увімкнути Sticky Bit.
find /usr -type f -perm -4000– знайти файли із SUID у каталозі/usr.
🛡️ Розширені списки доступу ACL
getfacl file– переглянути ACL.
setfacl -m u:user:rw file– призначити користувачу право читання та запису.
setfacl -m g:group:rx dir– призначити групі читання та проходження каталогу.
setfacl -x u:user file– видалити окремий ACL-запис.
setfacl -b file– прибрати розширені ACL-записи.
setfacl -d– налаштувати ACL за замовчуванням для каталогу.
📁 Стандартні права нових файлів
umask– переглянути поточну маску.
umask 022– типовий режим для відкритих на читання файлів.
umask 027– обмежити доступ для інших користувачів.
umask 077– за типової конфігурації залишити доступ лише власнику.
Права доступу в Linux визначають, як користувачі та процеси взаємодіють із файлами, каталогами й системними ресурсами. Правильне налаштування дозволів допомагає не лише уникати помилок під час роботи застосунків, а й обмежувати наслідки потенційної компрометації системи.
У третій частині серії ми розібрали стандартну модель UGO, значення прав rwx, числовий і символьний запис дозволів, а також команди chmod, chown і chgrp. Окремо розглянули логіку перевірки доступу ядром Linux, спеціальні біти SUID, SGID і Sticky Bit, розширені списки ACL та механізм umask.
Для DevOps ці інструменти необхідні під час розгортання застосунків, налаштування серверів і організації спільної роботи. Для DevSecOps вони допомагають контролювати привілеї, знаходити небезпечні конфігурації та зменшувати ризики несанкціонованого доступу.
У четвертій, завершальній частині серії «Linux для DevOps і DevSecOps» перейдемо до процесів і керування системою. Розглянемо PID, PPID, сигнали, команди ps, top, htop, kill і nice, а також керування службами через systemd та аналіз їхньої роботи.
