Зошто OpenVPN кука не ја наоѓа датотеката покрај нејзината скрипта

Куките што работат без грешка и сепак пријавуваат датотека што недостига обично гледаат на погрешно место, а не не успеваат во својата работа. Релативните патеки во скриптата се решаваат во однос на работниот именик на процесот, а услугата започнува со работен именик што вие не сте го избрале. Датотеката покрај скриптата и датотеката што процесот ја отвора се иста работа само кога нешто ги закотвува. Оваа разлика објаснува голем дел од неуспесите на куките што погрешно се читаат како проблеми со дозволи.

Проверете ја патеката пред дозволите, бидејќи грешка со дозвола на погрешната датотека е сепак погрешната датотека.

Релативната патека се решава во однос на процесот, не на датотеката

Кога скриптата повикува open("policy.json"), јадрото го решава името во однос на тековниот работен именик на процесот. Ништо од сопствената местоположба на скриптата не учествува во тоа пребарување. OpenVPN стартува куки од именик што сам го избира, а опцијата cd може да го смени, па скриптата тестирана рачно од сопствената папка се однесува поинаку кога демонот ја извршува. Рачниот тест поминува, извршувањето на услугата не успева, а линијата во дневникот го споменува само името што недостига.

Python ја открива местоположбата на скриптата како __file__, и токму тоа овозможува закотвување. Path(__file__).resolve().parent / "policy.json" гради патека од датотеката, а не од процесот. Таа една линија ја отстранува зависноста од работниот именик без да смени нешто во привилегиите.

Закответе ја патеката намерно, потоа проверете што прави resolve

resolve() следи симболични врски, па инсталацијата што ја врзува куката на место се закотвува на целта на врската, а не на именикот што ја држи врската. Тоа обично е посакуваното за верзионирано распоредување, а е погрешно за распоред што очекува податоци покрај симболичката врска. Одлучете што мисли распоредувањето и напишете го кодот согласно тоа, наместо да ја откриете разликата во производство. Path(__file__).parent без resolve() го задржува сопствениот именик на врската.

Ако податоците и припаѓаат на инстанцата, а не на програмата, земете апсолутна патека од конфигурацијата. Тврдото кодирање на локација ја врзува куката за еден распоред на домаќин.

Поминете четири граници по ред

Започнете со работниот именик: споредете го WorkingDirectory, опцијата cd на OpenVPN и секој обвивка што го менува именикот пред exec. Потоа потврдете ја решената локација, бидејќи датотека со слично име во друго распоредување може да одговори на пребарувањето и да ја скрие грешката. Следно доаѓа погледот на датотечниот систем: chroot или mount именски простор на услугата можат апсолутна патека на домаќинот едноставно да ја направат отсутна. Последен е идентитетот на пристап, што е прашање одделно од видливоста.

ProtectHome и PrivateTmp кријат различни локации и ниту едно не се појавува во список на именик земен од домаќинот. Патека што постои за root во школка може да биде невидлива внатре во именскиот простор на единицата, и затоа тестирањето на истата команда надвор од услугата докажува толку малку.

Поправете го пребарувањето без да ја проширите услугата

Закотвувањето на патеката ја решава само првата граница. То не открива именик што услугата го крие и не му дава на непривилегиран сметка пристап до датотека само за root. script-security покачувањето менува кои скрипти OpenVPN ќе ги изврши; тоа нема никакво влијание врз тоа каде се решава релативното име. Менувањето на работниот именик за целата услуга е пошироко од проблемот, бидејќи секоја друга релативна патека на сертификат, дневник или помошник се движи со неа.

Преферирајте ја тесната поправка: детерминистичка патека во скриптата, експлицитна конфигурациска вредност за податоците на инстанцата и сопственост на датотеки што одговара на сметката под која куката навистина работи.

Запишете докази што ја именуваат границата

Корисен извештај за неуспех содржи три работи: точната патека што куката ја обидела, околината што ја создала и која граница одбила. Испечатете ја решената патека и исклучокот без да ја излеете содржината на датотеката. Таа тројка го одделува погрешното закотвување од скриен mount и од одбивање дозвола, кои се три различни поправки.

Тврдењето дека root може да ја прочита датотеката од терминал одговара на едно од тие прашања и на ниту едно од другите. Наместо тоа тестирајте од сопствениот контекст на услугата.