Виправити дозволи масово: взяти власність без порушення наслідування

Зрозуміти, що насправді означає «наслідування» в Linux

Люди говорять «наслідування», ніби це універсальна властивість дозволів. Це не так. В Linux наслідування — це викликане явище, створене кількома окремими механізмами:

1) POSIX бітові режими (chmod) не наслідуються

Директорії мають дозволи; файли мають дозволи. Створення нового файлу в директорії не «усвідомлює» бітів режиму батьківської директорії. Новий файл отримує режим, заснований на процесі-створювачі та його umask, а не на батьківській rwx.

2) setgid на директоріях — це наслідування групи (так собі)

Якщо в директорії встановлено біт setgid (chmod g+s), новостворені файли та директорії зазвичай наслідують групову власність директорії. Це старомодний, але ефективний інструмент для спільних робочих папок команд.

3) POSIX ACL дають справжнє наслідування через «default ACL»

ACL дають іменованих користувачів/групи, маски та значення за замовчуванням. Директорія може мати default ACL, які застосовуються до нових об’єктів у ній. Це найближче до Windows-подібного наслідування в рідному POSIX ACL.

4) «Взяти власність» — це політичне рішення, а не просто команда

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

5) ACL mask — мовчазний вбивця

На системах з POSIX ACL, запис mask може обмежувати ефективні дозволи для іменованих користувачів та груп. Тож ви можете «надати» доступ і все одно отримати Permission denied, бо маска його прижимає. Ось як раціональні інженери втрачають півдня.

Одна перефразована ідея від авторитетного фахівця з надійності підходить сюди: paraphrased idea — «Усе виходить з ладу; проектуйте так, щоб відмови були передбачуваними й відновлюваними.» — Richard Cook (paraphrased idea)

Цікаві факти та історія для аргументів

• Факт 1: Традиційні Unix-дозволи (власник/група/інші) походять з раннього Unix 1970-х і оптимізовані для простоти, а не для виразності.
• Факт 2: Біти setuid/setgid/sticky були не стільки «функціями безпеки», скільки прагматичними хаками для багатокористувацьких систем зі спільними робочими процесами.
• Факт 3: POSIX ACL стали масовими в Linux на початку 2000-х, коли підприємства потребували тоншого контролю доступу, ніж могли дати бітові режими.
• Факт 4: Запис ACL mask існує, щоб давати верхню межу ефективних дозволів — чудово для контролю, погано для інтуїції.
• Факт 5: На багатьох Linux-файлових системах підтримка ACL вбудована, але для керування потрібно користувацьке ПЗ (getfacl, setfacl).
• Факт 6: SMB/CIFS (Samba) часто відображає Windows-ACL на POSIX ACL або розширені атрибути, що може виглядати «правильно» у Windows і «дивно» в Linux.
• Факт 7: NFS має кілька моделей безпеки в різних версіях; те, що «працює» на NFSv3 з мапінгом UID, може зламатися, якщо змінити управління ідентичностями.
• Факт 8: rsync може зберігати власність, бітові режими, xattrs і ACL — але лише якщо ви явно попросите і цільова система це підтримує.
• Факт 9: Sticky bit на директоріях (як у /tmp) — простий, але потужний механізм безпеки для багатьох користувачів: можна створювати файли, але не видаляти чужі.

Швидкий план діагностики (швидко знайти вузьке місце)

Це послідовність «перестаньте гадати». Запускайте її по порядку. Вона звужує проблему до ідентичності, файлової системи, семантики ACL або інструментів.

Перш за все: ідентифікуйте шлях доступу та трансляцію ідентичності

1. Звідки йде доступ? локальний shell, SSH, Samba, NFS, контейнерний bind mount?
2. Хто користувач? числовий UID/GID має більше значення, ніж імена у багатьох випадках відмов.
3. Чи є невідповідність ідентичностей? зміни в AD/LDAP/SSSD, idmap, проблеми NFS idmapping.

Друге: перевірте ефективні дозволи у точці відмови

1. Біт виконання директорії (x) на кожному сегменті шляху-родителя.
2. Записи POSIX ACL та ACL mask.
3. Опції монтування (наприклад, noacl, nosuid, root squashing у NFS).

Третє: вирішіть, чи ви виправляєте власність, ACL або обидва

1. Якщо власність неправильна, але ACL правильні — віддавайте перевагу цільовому chown.
2. Якщо дефолтні ACL відсутні — виправляйте дефолтні ACL директорії, а не кожен файл.
3. Якщо модель неконсистентна — зробіть снапшот/бекап метаданих і відновіть з відомої політики.

Жарт 1: Якщо ваша модель дозволів потребує 40-слайдового презентації, це не модель. Це заручникова ситуація.

Практичні завдання: команди, виводи та рішення (12+)

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

Завдання 1: Підтвердити тип файлової системи та опції монтування (ACL можуть бути відключені)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /srv/share
/dev/sdb1 /srv/share ext4 rw,relatime,errors=remount-ro

Значення: Ви на ext4 з нормальними опціями. Якби ви бачили noacl (або NFS-монтаж без очікуваних можливостей), очікували б іншої поведінки ACL.

Рішення: Якщо опції монтування конфліктують зі стратегією дозволів, виправте конфігурацію монтування перед тим, як чіпати дозволи. Інакше ви «виправите» метадані, які ядро ігнорує.

Завдання 2: Відтворити проблему від імені постраждалого користувача і зафіксувати точну помилку

cr0x@server:~$ sudo -u alice bash -lc 'cd /srv/share/team && touch testfile'
touch: cannot touch 'testfile': Permission denied

Значення: Це помилка запису/створення, а не читання. Для створення в директорії потрібні w і x на директорії.

Рішення: Зосередьтеся на дозволах/ACL директорії, а не на дозволах файлів. Можна нескінченно chmod файли; створення все одно буде зазнавати невдачі.

Завдання 3: Перевірити числову ідентичність і членство в групах (імена можуть брешуть)

cr0x@server:~$ id alice
uid=10501(alice) gid=10501(alice) groups=10501(alice),12000(finance),12010(shared-team)

Значення: Alice в групі shared-team. Якби не була — «проблема з дозволами» могла б бути проблемою надання чи групової налаштування.

Рішення: Якщо членство в групі відсутнє, спочатку виправте IAM/LDAP/AD/SSSD. Не замазуйте проблему ідентичності дозволами з надто відкритими ACL.

Завдання 4: Перевірити біт режиму директорії (чи є виконання?)

cr0x@server:~$ namei -l /srv/share/team
f: /srv/share/team
drwxr-xr-x root root /
drwxr-xr-x root root srv
drwxr-x--- root shared-team share
drwxrwx--- root shared-team team

Значення: Шлях виглядає доступним для групи на /srv/share і /srv/share/team. Якби будь-який батько не мав x для відповідного класу, доступ би не проходив.

Рішення: Якщо обхід шляху відмовляє, спочатку виправте батьківську директорію. Ідеальний ACL на листовій директорії не допоможе, якщо ви не можете до неї дістатися.

Завдання 5: Перевірити ACL та маску на директорії

cr0x@server:~$ getfacl -p /srv/share/team
# file: /srv/share/team
# owner: root
# group: shared-team
user::rwx
group::rwx
other::---
mask::r-x
default:user::rwx
default:group::rwx
default:other::---

Значення: mask::r-x обмежує ефективні дозволи групи до читання/виконання, хоча group::rwx існує. Це може блокувати запис.

Рішення: Виправте маску (setfacl -m m::rwx) або знову застосуйте записи ACL з правильною обробкою маски. Не додавайте користувачів бездумно — вас все одно будуть блокувати.

Завдання 6: Показати ефективні ACL-права (уникнути самообману)

cr0x@server:~$ getfacl -p /srv/share/team | sed -n '1,20p'
# file: /srv/share/team
# owner: root
# group: shared-team
user::rwx
group::rwx              #effective:r-x
other::---
mask::r-x
default:user::rwx

Значення: Анотація #effective показує правду: група фактично має r-x, а не rwx.

Рішення: Якщо ефективні дозволи не відповідають наміру, розглядайте маску як елемент конфігурації першого порядку, а не як думку після.

Завдання 7: Виправити лише маску ACL директорії (хірургічна зміна)

cr0x@server:~$ setfacl -m m::rwx /srv/share/team
cr0x@server:~$ getfacl -p /srv/share/team | grep -E 'mask|group::'
group::rwx
mask::rwx

Значення: Маска тепер дозволяє запис. Якщо користувачі досі не можуть створювати файли, наступний підозрюваний — дефолтні ACL і umask.

Рішення: Повторно протестуйте створення від імені користувача. Якщо виправлено — зупиніться. Не продовжуйте «поліпшувати» дозволи після вирішення інциденту.

Завдання 8: Перевірити дефолтні ACL (наслідування для нових файлів)

cr0x@server:~$ getfacl -p /srv/share/team | grep -E '^default:'
default:user::rwx
default:group::rwx
default:other::---

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

Рішення: Якщо потрібно, щоб кілька груп наслідували доступ, додайте дефолтні іменовані записи груп і встановіть відповідну дефолтну маску.

Завдання 9: Додати дефолтний ACL для групи-співпрацівника (і зберегти наслідування)

cr0x@server:~$ setfacl -m d:g:finance:rwx /srv/share/team
cr0x@server:~$ setfacl -m d:m::rwx /srv/share/team
cr0x@server:~$ getfacl -p /srv/share/team | grep -E 'default:group:finance|default:mask'
default:group:finance:rwx
default:mask::rwx

Значення: Нові файли/директорії під /srv/share/team будуть наслідувати запис ACL для групи finance за умови дефолтної маски.

Рішення: Якщо мета — наслідування, завжди налаштовуйте дефолти на директоріях. Не рекурсивно накладай ACL на існуючі файли, якщо це не необхідно.

Завдання 10: Підтвердити setgid на директорії (безперервність групової власності)

cr0x@server:~$ stat -c '%A %U %G %n' /srv/share/team
drwxrwx--- root shared-team /srv/share/team

Значення: Біт setgid не показаний (s з’явився б у позиції групового виконання). Без нього нові файли можуть отримувати первинну групу творця, а не shared-team.

Рішення: Для спільних директорій увімкніть setgid, якщо немає вагомої причини не робити цього.

Завдання 11: Увімкнути setgid і перевірити поведінку тестовим файлом

cr0x@server:~$ chmod g+s /srv/share/team
cr0x@server:~$ stat -c '%A %U %G %n' /srv/share/team
drwxrws--- root shared-team /srv/share/team
cr0x@server:~$ sudo -u alice bash -lc 'touch /srv/share/team/owned-by-group && stat -c "%U %G %n" /srv/share/team/owned-by-group'
alice shared-team /srv/share/team/owned-by-group

Значення: Групова власність тепер залишається послідовною. Це зменшує майбутні тікети «чому цей файл належить не тій групі?».

Рішення: Тримайте setgid на директоріях високої колаборації. Скучно — добре.

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

cr0x@server:~$ find /srv/share/team -maxdepth 2 -printf '%u:%g %m %p\n' | head
root:shared-team 2770 /srv/share/team
root:shared-team 2770 /srv/share/team/projects
bob:shared-team 0660 /srv/share/team/projects/notes.txt
carol:finance 0660 /srv/share/team/projects/budget.xlsx

Значення: У вас змішана власність та групи. Бездумний chown -R root:shared-team перезапише навмисні патерни власності по проєкту.

Рішення: Якщо змішана власність очікувана, уникайте глобального chown. Якщо це випадковість, визначте правила (що має змінитися, що має залишитись).

Завдання 13: Змінити власність безпечно з фільтрами (ціль лише на те, що неправильно)

cr0x@server:~$ find /srv/share/team -group finance -print | head -n 3
/srv/share/team/projects/budget.xlsx
/srv/share/team/projects/q1
/srv/share/team/archive/old

Значення: Ці об’єкти мають групу finance. Можливо, це неправильно. Можливо, це правильно. Тепер ви знаєте, де вони.

Рішення: Використовуйте предикати find, щоб обмежити масштаби змін. Ваш майбутній «я» оцінить стриманість.

Завдання 14: Виконати scoped chgrp (лише група) і перевірити один зразок

cr0x@server:~$ sudo chgrp shared-team /srv/share/team/projects/budget.xlsx
cr0x@server:~$ stat -c '%U %G %n' /srv/share/team/projects/budget.xlsx
carol shared-team /srv/share/team/projects/budget.xlsx

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

Рішення: Віддавайте перевагу chgrp над chown, коли власність не є проблемою.

Завдання 15: Зробити резервну копію ACL та xattr перед масовими правками (план відкату)

cr0x@server:~$ getfacl -R -p /srv/share/team > /root/team.acl.backup
cr0x@server:~$ wc -l /root/team.acl.backup
48231 /root/team.acl.backup

Значення: У вас є текстова копія метаданих ACL. Не досконало, але реальний важіль для відкату.

Рішення: Якщо ви не можете зробити снапшот, принаймні зафіксуйте метадані. Масові зміни дозволів без плану відкату — гра з робочими даними.

Завдання 16: Відновити ACL з бекапу, якщо накоїли лиха

cr0x@server:~$ setfacl --restore=/root/team.acl.backup
cr0x@server:~$ echo $?
0

Значення: Код виходу 0 означає успішне відновлення. Вам все одно потрібні вибіркові перевірки.

Рішення: При відновленні підтверджуйте кілька критичних директорій і файлів. Довіряй, та перевіряй — особливо після того, як довели, що ви помилкові.

Стратегія масових змін власності без побічних наслідків

«Взяти власність» зазвичай означає одне з трьох:

• Операційний контроль: сервісний обліковий запис або група адміністраторів повинні мати можливість пізніше ремонтити дозволи.
• Виправлення доступу: кінцевим користувачам потрібно знову мати читання/запис.
• Забезпечення політики: все в дереві має відповідати відомому стандарту.

Ці цілі вимагають різних тактик. Обробляйте їх по-різному, інакше ви виправите інцидент і зламаєте модель управління. Так, обидва варіанти погані; один просто з’явиться в аудиті замість в pager’ів.

Коли не слід запускати chown -R

Рекурсивна зміна власності підходить, коли поточні власники явно невірні (наприклад, усе належить застарілому UID міграції або root через відновлення). Вона не підходить, коли:

• Дерево містить кілька проєктів з різними власниками за замовчуванням.
• Додатки покладаються на конкретних власників для меж безпеки.
• ACL вже кодують політику доступу, а власність використовується лише для «хто може chmod».

Взяти власність, зберігаючи наслідування: безпечний шаблон

Ось шаблон, який працює в більшості спільних файлових налаштувань:

1. Спочатку виправте наслідування на рівні директорій: setgid + дефолтні ACL + правильні маски.
2. Припиніть використовувати власність як контроль доступу у спільних деревах. Використовуйте групову політику + ACL для доступу, залишайте власність для адміністративного контролю.
3. Нормалізуйте лише те, що потрібно нормалізувати: директорії та файли, критичні для співпраці, а не історичні архіви, якщо це не потрібно.
4. Підтвердіть реальними діями користувачів: створення, перейменування, видалення, редагування. Читання — це легка частина.

Що означає «не порушувати наслідування» насправді

Це означає, що ви випадково не видалите:

• дефолтні записи ACL на директоріях,
• setgid на колабораційних директоріях,
• потрібні значення ACL mask,
• очікування мапування Samba/NFS (ID, xattrs),
• вимоги додатків до дозволів.

Жарт 2: chmod 777 — це як відключити пожежну сигналізацію, бо вона гучна. Тихо, так. Краще — ні.

Три корпоративні міні-історії з польових боїв

Міні-історія 1: Інцидент через хибне припущення

У них був Linux-файловий сервер, який експортував шар по Samba. Новий інженер — розумний, швидкий, небезпечно оптимістичний — припустив, що Windows-подібне наслідування «зберігається в папці» і природно спускається вниз.

Під час реорганізації вони створили нову топ-рівневу директорію, скопіювали туди дані й налаштували дозволи зверху, використовуючи Windows-клієнт. У Explorer усе виглядало правильно. Усі пішли додому.

Наступного ранку дизайн-команда не могла зберегти файли. Директорія показувала доступ «Modify», але кожне збереження зазнавалo невдачі. Інженер перевірив налаштування шару і нічого не знайшов. Класика.

Справжня проблема: нова директорія не мала дефолтних POSIX ACL-записів, а маска ACL в деяких директоріях була занадто обмежувальною. Файли, створені деякими застосунками, отримали режим, обмежений umask, і не мали наслідних ACL-записів. Windows-клієнти показували дружню абстракцію; Linux-сторона виконувала іншу реальність.

Виправлення не було масовою рекурсивною перезапискою ACL. Вони встановили дефолтні ACL у потрібних директоріях, виправили маски, увімкнули setgid, а потім зачепили лише «гарячі точки», де створювалися файли. Хибне припущення полягало не в синтаксисі, а в тому, яка система є джерелом істини.

Міні-історія 2: Оптимізація, що дала назад

Команда зберігання хотіла прискорити нічне завантаження у спільний датасет. Хтось запропонував: «Запустимо інгест як root, тоді уникнемо перевірок дозволів і все піде швидше». Це спрацювало. Інгест завершився раніше. Люди тихенько пораділи — ті хвилини, які відрізали роботу, рідко приносять помітні святкування.

Два тижні по тому користувачі почали скаржитися на випадкову неможливість редагувати файли. Це було неузгоджено: одна директорія була нормальною, сусідня — ні. Квитки підтримки перетворилися на Slack-нитки, потім на зустрічі, потім знову в Slack. Продуктивність помирала тисячами «можеш спробувати ще?» повідомлень.

Корінна причина була тонкою: файли, створені від root, мали режими та ACL, що не відповідали моделі співпраці. Деякі файли не отримали іменованих ACL-записів, інші — отримали обмежувальні маски через те, як скрипти застосовували ACL. Інгест був «швидшим», бо обходив обмеження коректності.

Відкат не був красивим. Потрібно було знайти файли, створені інгест-користувачем за діапазон дат, відновити правильну групову власність і застосувати політику ACL там, де потрібно. Урок закарбувався: оптимізаційні хакі, що торкаються ідентичності й дозволів — це борговий інструмент з капіталізованим відсотком.

Міні-історія 3: Скучно правильна практика, що врятувала день

Інша організація мала дисципліну: перед будь-якою великою зміною дозволів вони рекурсивно зберігали ACL у файл з міткою часу і робили снапшот файлової системи, якщо доступно. Це було прописано в шаблоні змін, і всі дотримувались, бо ротація on-call — спільне страждання.

Під час міграції скрипт, що мав виправити групову власність, випадково запустився на неправильному mountpoint. Він змінив групову власність у робочому шарі, яким користувалися кілька команд. Моніторинг мовчав; проблеми з дозволами рідко виглядають як CPU-сплески. Замість цього кричали користувачі, що менш дружньо для машинного сигналу.

Оскільки у них був попередній ACL-бекап і снапшот, відновлення було механічним: тимчасово перемонтувати в readonly, відновити ACL, відкотити снапшот для ураженого піддерева, а потім повторно застосувати потрібну зміну з виправленим охопленням. Простій не був нульовим, але він був обмеженим. Ніякої археології, жодного гадання.

Що їх врятувало — не героїзм. Це була нудьга: чекліст, артефакт для відкату і відмова вважати «працю з дозволами» занадто простою, щоб їй потрібні були запобіжні засоби.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «Користувач має rwx на директорії, але все одно не може створювати файли»

Корінна причина: Маска ACL стискає ефективні дозволи (mask::r-x), або користувач фактично не має дозволу запису на директорію.

Виправлення: Перевірте через getfacl і зверніть увагу на #effective. Відрегулюйте маску: setfacl -m m::rwx DIR і при потребі setfacl -m d:m::rwx DIR.

2) Симптом: «Нові файли мають неправильну групу»

Корінна причина: Відсутній біт setgid на директоріях, або застосунок створює в місці без setgid.

Виправлення: chmod g+s DIR. Підтвердіть через stat і протестуйте створення як звичайний користувач.

3) Симптом: «Все виглядає нормально в Linux, але Windows-користувачі не можуть редагувати»

Корінна причина: Несумісність відображення Samba ACL, xattrs не збережені, або Windows очікує семантику наслідування, якої POSIX дефолти не дають.

Виправлення: Перевірте дефолтні POSIX ACL на директоріях; переконайтесь, що шар налаштований узгоджено; підтвердіть підтримку xattr і що під час копіювання/міграції збережено ACL.

4) Симптом: «Після chmod -R доступ став гірший»

Корінна причина: Бітові режими змінились, але ACL залишились; chmod може взаємодіяти з маскою ACL і видаляти потрібні шляхи доступу.

Виправлення: Припиніть рекурсивний chmod у деревах, керованих ACL. Застосуйте потрібну політику ACL на директоріях і виправте маски. Відновіть з ACL-бекапу, якщо він є.

5) Симптом: «Root не може це виправити через NFS»

Корінна причина: Root squashing мапує root на анонімний UID, блокуючи зміни власності.

Виправлення: Ремонтуйте дозволи на боці сервера (не на клієнтському монтуванні), або свідомо і тимчасово змініть політику експорту NFS через change control.

6) Симптом: «Деякі директорії записувані; інші ідентичні — ні»

Корінна причина: Неконсистентні дефолтні ACL між директоріями, часто через часткові міграції або точкові виправлення.

Виправлення: Порівняйте через getfacl «хорошу» і «погану» директорію. Нормалізуйте дефолти директорій; уникайте змін історичних файлів без потреби.

Контрольні списки / покроковий план

Покроковий план для безпечного масового фіксу

1. Уточніть модель: вирішіть, які групи/користувачі повинні мати читання/запис і які директорії потребують поведінки наслідування.
2. Зніміть артефакти для відкату: зробіть снапшот якщо доступно; інакше getfacl -R -p у файл.
3. Підтвердіть шлях доступу: локальний vs Samba vs NFS; підтвердіть ID-мепінг і членство в групах.
4. Виберіть пілотне піддерево: одна папка проєкту, а не весь шар.
5. Виправте наслідування на директоріях: setgid + дефолтні ACL-записи + дефолтні маски.
6. Виправте маски ACL директорій: переконайтесь, що ефективні дозволи відповідають наміру.
7. Перетестуйте реальні дії: створення, перейменування, видалення, редагування та створення з застосунку (не лише touch).
8. Нормалізуйте групову власність там, де потрібно: віддавайте перевагу chgrp з обмеженими find-виразами.
9. Лише потім розглядайте рекурсивні операції: коли ви можете описати зону ураження і маєте план відкату.
10. Прогресуйте систематично: застосуйте той самий шаблон виправлення до наступного піддерева; не імпровізуйте для кожної директорії.
11. Документуйте правила: очікування setgid, дефолтні ACL-записи та причини встановлення масок.
12. Запобіжні заходи: періодична перевірка, що позначає директорії без setgid або дефолтних ACL.

Чекліст перед зміною (в голові)

• Чи є у мене снапшот або ACL-бекап?
• Чи знаю я, яким протоколом користуються (Samba/NFS/локально)?
• Чи відтворив я проблему як реальний користувач через sudo -u?
• Чи перевіряв я ACL mask та ефективні дозволи?
• Чи виправляю я директорії (наслідування) перед файлами (симптоми)?
• Чи використовую я scoped find замість звички -R?

Чекліст після зміни (доведіть, що виправлено)

• Створіть файл, директорію і перейменуйте обидва як постраждалий користувач.
• Перевірте, що групова власність нових об’єктів відповідає очікуванню (setgid працює).
• Переконайтесь, що друга група співпрацівників може отримати доступ, якщо це політика (дефолтний ACL працює).
• Вибірково перевірте «відомо чутливу» директорію, щоб упевнитися, що ви не розширили доступ.
• Збережіть ACL-бекап/снапшот до наступного бізнес-циклу.

FAQ

1) Що означає «взяти власність» у контексті спільної папки?

Зазвичай: зробити послідовного адміністративного власника (часто root або сервісний акаунт), використовуючи групи/ACL для надання доступу користувачам. Власність — для контролю; ACL — для співпраці.

2) Чому іноді chmod здається, що «ламав» права ACL?

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

3) Як зберегти наслідування для нових файлів?

В Linux: використовуйте setgid на директоріях для наслідування групи і дефолтні ACL для наслідування дозволів. Перевіряйте дефолтні маски, щоб наслідувані дозволи були ефективними.

4) Чи застосовувати ACL рекурсивно до всіх файлів?

Не за замовчуванням. Спочатку виправте дефолти директорій; вони впливають на майбутній вміст. Рекурсивне виправлення існуючих файлів іноді необхідне після міграцій, але це підвищує ризик і час виконання, і легко призвести до надмірного розкриття даних.

5) Я запустив chown -R і тепер додатки падають. Який найшвидший відкат?

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

6) Чому користувач може перерахувати директорію, але не отримати доступ до файлів всередині?

Перерахування вимагає read на директорію; доступ до конкретного імені вимагає execute на директорії та відповідних дозволів на файл. Відсутній x на батьківській директорії — часта причина.

7) У чому різниця між записом ACL і ACL mask?

Записи виражають намірні дозволи для користувачів/груп. Маска — це максимальна ефективна дозволена поверхня для іменованих користувачів/груп і класу групи. Якщо маска обмежувальна, записи не працюватимуть як очікується.

8) Як Samba і Windows-наслідування пов’язуються з POSIX дефолтами?

Samba може відображати Windows ACL на POSIX ACL і/або зберігати багатші метадані в xattrs. Windows-«наслідування» не завжди чисто транслюється. В Linux дефолтні ACL на директоріях — найближчий аналог для наслідування нових об’єктів.

9) Чи безпечно виправляти дозволи, поки користувачі активні?

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

Висновок: наступні кроки, які варто зробити

Якщо ви дивитесь на брудне дерево дозволів, не починайте з рекурсії. Почніть з правди: підтвердьте ідентичність, підтвердьте семантику монтування, підтвердьте ефективні ACL (особливо маски), а потім виправляйте наслідування на рівні директорій. Саме звідти приходить стабільність.

Практичні наступні кроки:

1. Виберіть одну проблемну директорію і запустіть: namei -l, stat, getfacl і реальний тест створення від користувача.
2. Зробіть резервну копію ACL для піддерева перед будь-якими значущими змінами.
3. Встановіть setgid і дефолтні ACL на колабораційних директоріях; виправте маски, щоб «надано» означало «ефективно».
4. Обмежте зміни власності/групи find-предикатами; віддавайте перевагу chgrp перед chown, коли можете.
5. Після інциденту зафіксуйте політику і додайте аудиторську задачу для виявлення дрейфу перед наступною міграцією.

Дозволи не складні тому, що Linux складний. Вони складні тому, що люди непослідовні, а зберігання пам’ятає все.