PrivateTmp: куката написа файла, но къде отиде той?

Куките съобщават за успех, а същият път от shell все още изглежда празен. И двете твърдения могат да са верни едновременно, защото systemd услуга може да живее в свое собствено mount пространство с частна временна директория. След като това се разбере, интересният въпрос става дали записът изобщо е успял.

Две временни директории, един път

Настройката за изолация дава на юнита частен изглед към временните директории, вместо да ги прави само за четене. Процеси извън юнита не могат да видят какво пише той там, а всичко, което остави след себе си, се изхвърля, когато юнитът спре. Затова път, отпечатан от куката, и път, проверен от shell, може да сочат към различни обекти с едно и също име.

Това е проблем на видимост и изглежда като проблем на загуба на данни. Нищо не е изтрито, защото файлът просто се намира в пространство от имена, на което shell не е член. Същата команда се държи различно, когато се изпълни вътре в юнита, и това наблюдение обикновено решава спора. Прочетете настройките на юнита, преди да заключите нещо за записа.

Отделете невидимото от незаписваемото

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

systemctl show [email protected] -p PrivateTmp -p User -p Group -p RuntimeDirectory
systemctl show [email protected] -p MainPID --value
sudo ls -l /proc/PID/root/tmp/client-state

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

Дайте на споделените данни явно място

Данните, от които се нуждае само услугата, принадлежат в частната й временна директория. Данните, които друг процес трябва да чете, се нуждаят от път, определен за двамата, с посочен собственик, режим и срок. Решете кой от двата случая имате, преди да редактирате юнита. Повечето от тези инциденти идват от това частен файл да се третира като споделен.

[Service]
RuntimeDirectory=openvpn-hook-office
RuntimeDirectoryMode=0750

Директорията за изпълнение поставя папката под системната област за изпълнение, създава я за конфигурираните потребител и група на юнита и я премахва, когато юнитът спре. Добавете я чрез drop-in, за да остане юнитът на пакета непокътнат, после презаредете мениджъра и рестартирайте този екземпляр, приемайки, че клиентите му ще се свържат отново.

Запазете всяка директория за изпълнение, която инсталираният юнит вече изисква. Замяната на списъка вместо добавяне към него е чест начин да се счупи несвързана функция, която никой не свързва с промяната.

Два слоя привилегии могат да не съвпадат

Мениджърът на услуги създава директорията за конфигурирания потребител на юнита, докато VPN демонът може отделно да слезе до собствения си акаунт, преди да изпълни кука за връзка. Това са различни слоеве и те могат да назовават различни идентичности.

Директория, собственост на root, с ограничителен режим, е напълно видима за демон, който вече е свалил привилегии, и все още незаписваема от него. Тогава грешката се чете като проблем с права, макар пътят да съществува точно там, където сте очаквали. Сравнете собственика на директорията с идентичността, която куката съобщава. Когато се различават, режимът никога не е бил въпросът.

Проверете идентичността, под която куката наистина работи, преди да смените собствеността. Смяната на потребителя за изпълнение на услугата, за да поправите директория, може да промени достъпа до устройства и мрежовите привилегии другаде, което е голяма цена за малък проблем.

Проверете цялото предаване

Потвърдете четири неща наведнъж: куката пише под истинската си идентичност, предвиденият четец може да консумира файла, несвързани потребители не могат, а спирането на юнита почиства както е проектирано. Файл, появил се в споделената временна директория на хоста, не е изискване и обикновено е знак, че обменът така и не е получил свой път. Тествайте четеца след рестарт, не само при първото изпълнение. Поведението при почистване е част от дизайна, затова го наблюдавайте, вместо да го предполагате.

Постоянното състояние принадлежи някъде с подходящ жизнен цикъл, защото директорията за изпълнение е предназначена да изчезне. Изберете мястото по жизнен цикъл, а не по удобство. Този навик предотвратява следващата версия на същото разследване.