Журнал дописується, але не перестворюється: перевірте ACL каталогу
Дозапис у файл не потребує нового імені в каталозі; створення потребує. Порівняйте ACL доступу з успадкованими типовими значеннями, перш ніж щось розширювати.
Журнал, що постійно зростає, припиняє зростати в ту мить, коли щось його перестворює, і помилка повідомляє, що доступ заборонено. Спокусливий висновок — самому файлу журналу потрібно більше прав, — але файл може вже бути доступним для запису тим самим обліковим записом. Дозапис до наявного імені та створення нового імені — дві різні перевірки, і лише друга звертається до каталогу.
Дозапис і створення — різні перевірки
Відкриття наявного файлу для дозапису потребує права запису на цей файл і права пошуку в кожному каталозі на його шляху. Створення файлу потребує запису й пошуку в каталозі, що його містить, бо операція додає до нього ім'я. Заміна файлу через перейменування торкається обох каталогів та їхніх правил sticky bit.
| Operation | What must permit it | Typical failure message |
|---|---|---|
| Append to an existing log | File write access, path traversal | Permission denied on the file |
| Create a missing log | Directory write and search access | Permission denied on the path |
| Rename a replacement into place | Both directories, plus sticky restrictions | Permission denied or operation not permitted |
Уже відкритий дескриптор додає четвертий випадок. Процес може тримати дескриптор запису, відкритий до того, як він відмовився від привілеїв, і все ж не змогти повторно відкрити той самий шлях під своєю пізнішою ідентичністю. Успішні дозаписи й невдале створення можуть бути обидва правдою в один і той самий момент для одного процесу.
Типові ACL успадковуються, вони не надають
Запис, що починається з типового префікса, описує, що нові об'єкти успадковують від каталогу. Він нічого не надає самому каталогу і не виправляє ACL уже наявного файлу.
namei -l /var/log/openvpn/server.log
getfacl -p /var/log/openvpn
getfacl -p /var/log/openvpn/server.logЧитайте записи доступу окремо від типових і читайте маску. Іменований запис із повними правами все одно може бути обмежений маскою, тому ефективний коментар важливіший за літери в першому рядку.
Використовуйте розв'язаний шлях, а не шлях із конфігурації. Символічне посилання, точка монтування або повернутий каталог можуть розмістити справжній файл там, куди надане вами право ніколи не дістанеться. Спершу пройдіть шлях інструментом імен, потім порівняйте кожен рівень із відповідним обліковим записом. Здогадка про каталог верхнього рівня — це спосіб, у який виправлення приземляється на рівень вище.
Визначте, хто пише в цей момент
Перш ніж щось змінювати, перевірте сервісний юніт, його drop-in і власні налаштування облікового запису демона. Процес, що дописує, і процес, що перестворює, можуть відрізнятися: помічник ротації, письменник стану й вебчитач рідко поділяють ідентичність.
Запуск тесту з root-оболонки не відтворює обмеженого сервісу, і він завершиться успішно, поки сервіс продовжує збоїти. Відтворіть невдалу операцію під тим самим юнітом, з тим самим обліковим записом і тими самими налаштуваннями sandbox. Якщо не можете, запустіть юніт із тимчасовою оболонкою й перевірте ідентичність, яку він повідомляє. Усе інше вимірює ваш термінал, а не сервіс.
Якщо створення справді потрібне, дайте письменнику доступ до виділеного каталогу журналу, а доступ на читання для споживачів тримайте окремо. Зробити спільний обліковий запис або все дерево застосунку записуваним, щоб задовольнити один виклик журналювання, — це обмін малої проблеми на велику.
Виконуйте ротацію, не повертаючи проблему
Той, хто перестворює файл, вирішує його власника й режим на наступний цикл, тож узгодьте виправлення з конфігурацією ротації. Заміна, створена під іншим обліковим записом або з новим ACL, повертає збій після успішного виправлення.
Задавайте режим і групу під час створення, а не після, і перевіряйте наступну ротацію, а не наступний дозапис. Дозапис лише повторює тест, який уже пройшов. Якщо інструмент ротації пропонує налаштування режиму створення, використовуйте його замість chmod після створення. Проміжок між створенням і chmod — це саме той момент, коли наступний запис може збійнути.
Коли обрізання все одно збоїть, припиніть додавати права
Збій обрізання файлу, у який ви можете писати, не пояснюється правами каталогу, і додавання нових не допоможе. Погляньте натомість на атрибути й обмеження: атрибут append-only дозволяє запис лише в режимі дописування, а монтування лише для читання або sandbox сервісу можуть відхилити операцію, яку ACL дозволяє.
Перевірте обмеження файлової системи юніта й параметри монтування шляху, потім відтворіть точну операцію, яка збійнула. Розширення права, до якого ніколи не зверталися, лише приховує, яке обмеження було справжнім. Вилучайте по одному обмеженню за раз у тимчасовому юніті й повертайте його, перш ніж змінювати щось постійне.