PrivateTmp: хук записав файл, але куди він подівся?

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

Два тимчасові каталоги, один шлях

Налаштування ізоляції дає юніту приватний вид на тимчасові каталоги, а не робить їх лише для читання. Процеси поза юнітом не бачать, що він туди пише, а все, що він залишає після себе, відкидається, коли юніт зупиняється. Тому шлях, надрукований хуком, і шлях, перевірений з оболонки, можуть указувати на різні об’єкти з однаковим іменем.

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

Відокремте невидиме від незаписуваного

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

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, з обмежувальним режимом цілком видимий демону, який уже відмовився від привілеїв, і все ж недоступний йому для запису. Тоді помилка читається як проблема прав, хоча шлях існує саме там, де ви очікували. Порівняйте власника каталогу з особою, яку повідомляє хук. Коли вони різняться, режим ніколи не був питанням.

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

Перевірте всю передачу

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

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