Журналът расте, но не може да бъде пресъздаден: проверете ACL на директорията
Добавянето към файл не изисква ново име в директорията му, а създаването — да. Сравнете ACL за достъп с наследените по подразбиране, преди да разширявате каквото и да е.
Журнал, който непрекъснато расте, спира да расте в момента, в който нещо го пресъздаде, а грешката казва permission denied. Изкушаващото заключение е, че самият файл на журнала се нуждае от повече права, а файлът може вече да е записваем от същия акаунт. Добавянето към съществуващо име и създаването на ново са различни проверки и само втората се обръща към директорията.
Добавянето и създаването са различни проверки
Отварянето на съществуващ файл за добавяне изисква право за запис върху файла и право за търсене във всяка директория по пътя му. Създаването на файл изисква запис и търсене в съдържащата директория, защото операцията добавя име към нея. Замяната на файл чрез преименуване засяга и двете директории и правилата им за 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
Четете записите за достъп отделно от тези по подразбиране и четете маската. Именуван запис, който изброява пълни права, все още може да бъде ограничен от маската — затова ефективният коментар е по-важен от буквите на първия ред.
Използвайте разрешения път, а не пътя от конфигурацията. Символна връзка, точка на монтиране или завъртяна директория могат да поставят истинския файл там, където даденото от вас право никога не стига. Първо минете пътя с инструмента за имена, после сравнете всяко ниво със съответния акаунт. Гадаенето на горната директория е начинът поправката да попадне едно ниво по-високо.
Установете кой пише в този момент
Проверете unit-а на услугата, неговите drop-in файлове и собствените настройки на акаунта на демона, преди да промените нещо. Процесът, който добавя, и процесът, който пресъздава, може да са различни: помощник за ротация, писател на статус и уеб четец рядко споделят идентичност.
Пробно изпълнение от root shell не възпроизвежда ограничена услуга, и то ще успее, докато услугата продължава да се проваля. Възпроизведете неуспешната операция под същия unit, със същия акаунт и същите настройки на пясъчника. Ако не можете, стартирайте unit-а с временен shell и проверете идентичността, която съобщава. Всичко друго измерва вашия терминал, а не услугата.
Ако създаването наистина е нужно, дайте на писателя достъп до отделената директория за журнали и дръжте достъпа за четене на потребителите отделно. Правенето на споделен акаунт или цялото дърво на приложението записваемо, за да задоволи едно извикване за журнал, разменя малък проблем за голям.
Ротирайте, без да го връщате
Който пресъздава файла, решава собственика и режима му за следващия цикъл, затова съгласувайте поправката с конфигурацията за ротация. Заместител, създаден под друг акаунт или с нов ACL, връща отказа след успешна корекция.
Задавайте режима и групата при създаването, а не след това, и проверявайте следващата ротация, а не следващото добавяне. Добавянето само повтаря теста, който вече е минал. Ако инструментът за ротация предлага настройка за режим при създаване, използвайте нея вместо chmod след създаването. Пропастта между създаването и chmod е точно моментът, в който следващият запис може да се провали.
Когато отрязването все пак се провали, спрете да добавяте права
Неуспехът да отрежете файл, в който можете да пишете, не се обяснява с права на директорията и добавянето на още няма да помогне. Вместо това погледнете атрибутите и ограничението: атрибутът append-only позволява запис само в режим на добавяне, а монтиране само за четене или пясъчник на услугата могат да отхвърлят операция, която ACL разрешава.
Проверете файловите ограничения на unit-а и опциите за монтиране на пътя, после възпроизведете точно операцията, която се провали. Разширяването на право, което никога не е било питано, само прикрива кое ограничение е било истинското. Премахвайте по едно ограничение в отделен unit и го връщайте, преди да промените нещо трайно.