Налаштування ACL у Linux

У попередній статті ми розглядали, як влаштовані права доступу до файлів і каталогів у Linux, для чого потрібні команди chmod та chown і як керувати правами на читання, запис та виконання. І в більшості випадків стандартної моделі, коли кожен файл має власника, групу та набір прав для інших користувачів, цілком достатньо.

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

Для таких ситуацій у Linux передбачені ACL (Access Control Lists), або, простіше кажучи, списки контролю доступу. Вони дозволяють призначати індивідуальні дозволи користувачам і групам, зберігаючи, водночас, існуючих власників файлів і каталогів.

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

 

 

 

 

Що таке ACL і чим вони відрізняються від chmod

Стандартні права на файли та каталоги в Linux позначаються символами r (читання), w (запис) та x (виконання). Вони призначаються власнику файлу, його групі та іншим користувачам.

Наприклад, якщо ми виконаємо таку команду, вказавши будь-який каталог:

ls -ld /var/www/project

, то побачимо приблизно такий результат:

drwxr-x--- 2 www-data www-data 4096 Oct 20 12:00 /var/www/project

На цьому прикладі ми бачимо, що власником каталогу є системний користувач www-data. Він має повний доступ до каталогу, його група може читати вміст каталогу, а решта користувачів позбавлені доступу взагалі.

 

Тепер припустимо, що розробнику з логіном developer потрібно надати доступ до редагування файлів цього проєкту. Звичайно, ми можемо включити його до групи www-data, але тоді він отримає групові права й на інші об’єкти, де використовується ця група.

А ось ACL дозволяють надавати дозволи безпосередньо користувачеві developer і безпосередньо на цільову директорію або файл.

Нижче ми підготували наочну таблицю, у якій видно відмінності chmod/chown від інструменту ACL.

Можливість	chmod/chown	ACL
Права власника та основної групи	Так	Так
Індивідуальні права для інших користувачів	Ні	Так
Права для додаткових груп	Ні	Так
Успадкування прав доступу	Ні	Так
Обмеження прав через маску	Ні	Так

Виходить, що ACL доповнюють стандартні дозволи Linux, і обидва ці механізми працюють спільно. Тому зміна прав за допомогою chmod може вплинути на ACL, до чого потрібно бути готовим і постійно пам’ятати про це.

 

 

 

 

Встановлення ACL у Linux

У сучасних файлових системах ext4 та XFS, на яких працює більшість серверів та робочих станцій, підтримка POSIX ACL зазвичай увімкнена за замовчуванням. Для керування правами потрібні утиліти setfacl та getfacl.

У Debian та Ubuntu для їхнього встановлення необхідно виконати команди:

sudo apt update
sudo apt install acl

 

У Rocky Linux та AlmaLinux:

sudo dnf install acl

 

Щоб перевірити наявність утиліти у вашій системі, виконайте команду:

getfacl --version

Якщо ця команда працює і поверне результат, значить інструменти встановлені. Однак підтримку ACL самою файловою системою краще перевірити окремо, особливо якщо файли знаходяться на мережевому сховищі.

 

 

 

 

Як переглянути та змінити права ACL

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

sudo mkdir -p /srv/shared
sudo chmod 750 /srv/shared

 

Тепер переглянемо поточні права доступу до цього каталогу за допомогою встановленої нами вище утиліти:

getfacl /srv/shared

Приклад виводу:

# file: srv/shared
# owner: root
# group: root
user::rwx
group::r-x
other::---

 

Тут ми бачимо звичайні права Linux, і жодних додаткових записів поки що немає.

 

Призначення прав користувачеві

Тепер настав час надати додаткові права. Припустимо, що користувачеві developer потрібен повний доступ до каталогу. У такому випадку ми маємо додати відповідний запис:

sudo setfacl -m u:developer:rwx /srv/shared

У цій команді параметр -m змінює ACL, u:developer вказує користувача, а rwx задає права доступу.

 

Після цього перевіримо, що змінилося:

getfacl /srv/shared
user::rwx
user:developer:rwx
group::r-x
mask::rwx
other::---

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

 

Давайте перевіримо можливість створення файлу для нашого користувача, виконавши від його імені команду:

sudo -u developer touch /srv/shared/test.txt

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

 

Присвоєння прав групі

Як ми пам’ятаємо, у нас є група backup, якій потрібен доступ лише для читання, щоб створювати резервні копії. Щоб надати ці права, використовуємо аналогічну команду, але вказуємо не користувача u:developer, а групу g:backup:

sudo setfacl -m g:backup:rx /srv/shared

 

Якщо ж ці права потрібно застосувати до всього існуючого дерева, тоді використовуємо параметр -R :

sudo setfacl -R -m g:backup:rX /srv/shared

 

Велика літера X у команді setfacl працює трохи інакше, ніж мала літера x. Вона надає право на виконання всім каталогам, а звичайним файлам - лише в тому випадку, якщо вони вже мають дозвіл на виконання хоча б для однієї категорії користувачів.

Для каталогів право x необхідне, щоб користувач міг переходити до них і звертатися до файлів усередині.

 

А ось звичайним файлам, наприклад .txt, .html або .jpg, такий дозвіл найчастіше не потрібен.

Тому під час рекурсивного налаштування ACL зручніше використовувати X: тоді каталоги отримають потрібні права доступу, існуючі виконувані скрипти збережуть можливість запуску, а звичайні файли випадково не стануть виконуваними.

 

 

 

 

Успадкування прав через Default ACL

Звичайні ACL діють на конкретні файли та каталоги. Але якщо, наприклад, завтра в каталозі /srv/shared з’явиться новий файл, то користувач developer може не отримати до нього доступ.

Для вирішення цієї проблеми існують так звані Default ACL - успадковані дозволи. Вони встановлюються вже знайомою нам командою, але з використанням параметра -d:

sudo setfacl -d -m u:developer:rwx /srv/shared

Тепер нові файли, створені всередині нашого каталогу, а також його підкаталоги успадковуватимуть запис, створений для користувача developer.

 

Перевірити налаштування успадкування можна за допомогою команди:

getfacl -d /srv/shared

Приклад:

default:user::rwx
default:user:developer:rwx
default:group::r-x
default:mask::rwx
default:other::---

 

Однак у успадкуванні ACL є кілька особливостей. Припустимо, ми налаштували для користувача developer права rwx за замовчуванням:

sudo setfacl -d -m u:developer:rwx /srv/shared

Очевидно, що тепер усі нові файли та підкаталоги всередині /srv/shared успадковуватимуть цей запис. Але фактичні дозволи залежать від типу об’єкта, що створюється.

Наприклад, коли програма створює звичайний текстовий файл, вона найчастіше запитує права 0666 - читання та запис для всіх категорій користувачів, без дозволу на виконання. Тому навіть за наявності rwx у Default ACL користувач developer отримає для такого файлу лише rw-.

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

 

Що таке umask і як вона пов’язана з ACL

У Linux є ще один механізм управління правами доступу - umask (user file-creation mode mask). Це маска, яка обмежує права доступу під час створення нових файлів і каталогів.

За замовчуванням програми зазвичай запитують права 0666 для файлів і 0777 для каталогів. Але надавати всі ці права кожному користувачеві небезпечно, тому Linux застосовує umask, яка прибирає певні біти доступу.

Переглянути поточну маску можна за допомогою команди:

umask

Наприклад, якщо результат 0022, то нові об’єкти зазвичай отримають такі права:

Об'єкт	Запитувані права	umask	Підсумкові права
Файл	0666	0022	0644 (rw-r--r--)
Каталог	0777	0022	0755 (rwxr-xr-x)

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

 

Ви запитаєте, як це пов’язано з Default ACL? А ми вам відповімо.

Якщо для батьківського каталогу налаштовано Default ACL, Linux використовує успадковані правила та режим, запитуваний програмою. Звичайний umask при цьому окремо не застосовується.

Тому файл, створений у каталозі з Default ACL, може отримати ширші права доступу, ніж звичні 0644. Усе залежить від налаштованих правил успадкування та режиму створення.

І останній нюанс, про який не варто забувати. Default ACL діють лише на нові об’єкти. Вже існуючі файли зберігають колишні права доступу, тому щоб змінити їх, вам знадобиться звичайна команда setfacl -m, за необхідності з параметром -R для рекурсивного налаштування.

 

 

 

 

Маска ACL та ефективні права доступу

Вище ми розглянули umask, яка обмежує права під час створення нових файлів та каталогів. Але в ACL є й власна маска - mask, яка працює інакше.

Маска ACL визначає максимальні права доступу, які можуть отримати користувачі та групи через записи ACL. Вона впливає на фактичний доступ до вже існуючих файлів і каталогів, а не лише на права під час їх створення.

Наприклад, користувачеві developer призначено права rwx, але змінити файл він чомусь не може. Перевіримо ACL:

user:developer:rwx       #effective:r-x
mask::r-x

Тут запис user:developer:rwx дозволяє читання, запис і виконання. Але маска mask::r-x забороняє запис, тому фактичні (ефективні) права користувача обмежені до r-x. Саме їх показує коментар #effective.

 

Маска ACL поширюється на додаткові записи користувачів, основну групу файлу та додаткові групи. На власника файлу (user::) та інших користувачів (other::) вона не діє.

 

Змінити маску можна командою:

sudo setfacl -m m::rwx /srv/shared

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

Щоправда, тут теж є нюанс. Розширення маски може одночасно збільшити фактичні права кількох користувачів і груп. Тому перед зміною краще переглянути весь список за допомогою getfacl.

 

Ще одна відмінність від umask пов’язана з командою chmod. Так, якщо для файлу налаштовані розширені ACL, то зміна групових дозволів за допомогою chmod зазвичай змінює саме маску ACL. Наприклад:

sudo chmod g-w /srv/shared

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

 

Перевірити підсумкові дозволи можна командою:

getfacl /srv/shared

Отже, зафіксуємо, що umask обмежує права під час створення об’єктів, а маска ACL (mask) обмежує ефективні дозволи, що надаються записами ACL.

 

 

 

 

Видалення ACL та резервне копіювання

Видалити дозвіл конкретного користувача можна командою:

sudo setfacl -x u:developer /srv/shared

 

Видалити додаткові записи ACL доступу, відповідно:

sudo setfacl -b /srv/shared

 

Видалити всі успадковані правила Default ACL:

sudo setfacl -k /srv/shared

 

Взагалі-то, перед будь-якими масовими змінами ACL ми можемо убезпечитися від помилок, збереживши поточні ACL, наприклад, у звичайний текстовий файл acl-backup.txt , за допомогою команди:

sudo getfacl -R -p /srv/shared > acl-backup.txt

 

Відновлення з цього файлу виконується ще простіше:

sudo setfacl --restore=acl-backup.txt

 

Файл резервної копії містить вихідні шляхи, тому перед відновленням варто переконатися, що вони відповідають потрібним каталогам.

 

 

 

 

Як зберегти ACL під час перенесення файлів

На жаль, під час копіювання файлів додаткові дозволи можуть загубитися. Тому для перенесення, наприклад, за допомогою rsync використовуйте параметр -A:

sudo rsync -aA /var/www/project/ /backup/project/

У цьому прикладі параметр -a зберігає основні атрибути файлів, а параметр -A - саме списки ACL.

 

Якщо ж вам потрібно зберегти розширені атрибути файлової системи, тоді додайте параметр -X:

sudo rsync -aAX /var/www/project/ /backup/project/

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

 

 

 

 

Чому ACL можуть не працювати

Навіть якщо команда setfacl виконана без помилок, користувач не завжди отримує очікуваний доступ до файлів або каталогів. Причина тут може критися, наприклад, у масці ACL, недостатніх дозволах на батьківські каталоги або особливостях файлової системи. Іноді доступ блокують якісь додаткові механізми безпеки, такі, наприклад, як SELinux або AppArmor.

Давайте розберемо найпоширеніші проблеми, з якими можна зіткнутися під час налаштування ACL, та способи їх діагностики, але лише у наочному, табличному вигляді:

Проблема	Можлива причина	Перевірка
Permission denied	Недостатні ефективні права доступу	getfacl
Немає доступу до каталогу	Відсутній дозвіл x на шляху	namei -l
Operation not supported	Відсутня підтримка ACL	findmnt -T /path
Права доступу обмежені	Маска ACL	getfacl
Нові файли мають неправильні права	Помилка в налаштуванні Default ACL	getfacl -d
ACL зникли після перенесення	Атрибути файлів не збереглися	Параметри копіювання

 

Окремо перевірте SELinux або AppArmor, якщо вони використовуються на вашому сервері, оскільки ці механізми можуть забороняти доступ навіть при коректних ACL.

Є й особливість переміщення файлів усередині однієї файлової системи. У такому випадку файл зазвичай зберігає колишні ACL, а успадковані дозволи каталогу призначення при цьому заново не застосовуються.

 

 

 

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

А ось якщо у всіх користувачів однакові повноваження, тоді, звичайно, простіше використовувати звичайну групу Linux.

Ну а для повсякденного управління ACL вам вистачить лише двох команд: команди getfacl, яка показує існуючі дозволи, та команди setfacl, яка їх змінює.

І головне - під час роботи з ACL слід постійно перевіряти ефективні права, ретельно налаштовувати успадкування та зберігати ACL під час перенесення даних.