PrivateTmp: hook izrakstīja failu, bet kur tas palika?

Hooks ziņo par panākumiem, un tas pats ceļš joprojām izskatās tukšs no shell. Abi apgalvojumi var būt patiesi vienlaikus, jo systemd pakalpojums var dzīvot savā mount nosaukumtelpā ar privātu pagaidu direktoriju. Kad tas ir saprasts, interesantais jautājums kļūst par to, vai rakstīšana vispār izdevās.

Divas pagaidu direktorijas, viens ceļš

Izolācijas iestatījums unit dod privātu skatu uz pagaidu direktorijām, nevis padara tās tikai lasāmas. Procesi ārpus unit nevar redzēt, ko tas tur raksta, un viss, ko tas atstāj, tiek izmests, kad unit apstājas. Tāpēc hook izdrukātais ceļš un no shell pārbaudītais ceļš var norādīt uz dažādiem objektiem ar vienu un to pašu nosaukumu.

Tā ir redzamības problēma, un tā izskatās kā datu zuduma problēma. Nekas netika izdzēsts, jo fails vienkārši atrodas nosaukumtelpā, kuras dalībnieks shell nav. Tā pati komanda uzvedas citādi, kad to izpilda unit iekšienē, un tieši šis novērojums parasti izšķir strīdu. Pirms izdariet jebkādu secinājumu par rakstīšanu, izlasiet unit iestatījumus.

Atšķiriet neredzamo no neierakstāmā

Veiksmīga rakstīšana un neizdevusies atvēršana dod atšķirīgus pierādījumus, un šī atšķirība nosaka labošanu. Ja hook saka, ka fails ir izveidots, bet ārējs lasītājs to nevar atrast, jums ir nosaukumtelpas jautājums. Ja hook ziņo par atļaujas kļūdu vai neizdevušos atvēršanu, fails nekad netika rakstīts, un nekādas nosaukumtelpas izmaiņas nepalīdzēs.

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

Ceļš caur procesa sakni atklāj pakalpojuma paša failu sistēmas skatu, ievērojot atļauju pārbaudes uz šo procesu, kamēr tas vēl darbojas. Lasiet unit žurnālu tajā pašā sesijā, jo rakstīšanas kļūdu un trūkstošu failu ir viegli sajaukt, kad kāds jau ir izlēmis par cēloni.

Piešķiriet koplietotajiem datiem skaidru vietu

Dati, kas nepieciešami tikai pakalpojumam, pieder tā privātajai pagaidu direktorijai. Datiem, kas jālasa citam procesam, ir vajadzīgs abiem definēts ceļš ar norādītu īpašnieku, režīmu un derīguma termiņu. Pirms rediģējat unit, izlemiet, kurš no diviem gadījumiem jums ir. Lielākā daļa šo incidentu rodas no tā, ka privāts fails tiek uztverts kā koplietots.

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

Izpildlaika direktorija ievieto mapi sistēmas izpildlaika apgabalā, izveido to unit konfigurētajam lietotājam un grupai un noņem to, kad unit apstājas. Pievienojiet to ar drop-in, lai pakotnes unit paliktu neskarts, pēc tam pārlādējiet pārvaldnieku un restartējiet šo instanci, pieņemot, ka tās klienti atkārtoti savienosies.

Saglabājiet jebkuru izpildlaika direktoriju, ko instalētais unit jau prasa. Saraksta aizstāšana, nevis papildināšana, ir ierasts veids, kā salauzt nesaistītu funkciju, ko neviens nesaista ar izmaiņām.

Divi priviliģēto līmeņu slāņi var nesaskanēt

Pakalpojumu pārvaldnieks izveido direktoriju unit konfigurētajam lietotājam, bet VPN dēmons pirms savienojuma hook izpildes var atsevišķi pāriet uz savu kontu. Tie ir dažādi slāņi, un tie var nosaukt dažādas identitātes.

Root piederīga direktorija ar ierobežojošu režīmu ir pilnīgi redzama dēmonam, kas jau ir atteicies no privilēģijām, un tomēr tam tajā nevar rakstīt. Tad kļūda tiek lasīta kā atļauju problēma, lai gan ceļš pastāv tieši tur, kur jūs to gaidījāt. Salīdziniet direktorijas īpašnieku ar identitāti, ko ziņo hook. Kad tie atšķiras, režīms nekad nav bijis jautājums.

Pirms mainīt īpašumtiesības, pārbaudiet, ar kādu identitāti hook patiešām darbojas. Pakalpojuma izpildes lietotāja maiņa, lai salabotu direktoriju, var mainīt ierīču piekļuvi un tīkla privilēģijas citur, un tas ir augsta cena par mazu problēmu.

Pārbaudiet visu nodošanu

Vienlaikus apstipriniet četras lietas: hook raksta ar savu īsto identitāti, paredzētais lasītājs var izmantot failu, nesaistīti lietotāji nevar, un unit apstādināšana sakopj tā, kā projektēts. Faila parādīšanās resursdatora koplietotajā pagaidu direktorijā nav prasība, un tas parasti liecina, ka apmaiņa tā arī nesaņēma savu ceļu. Pārbaudiet lasītāju pēc restarta, ne tikai pirmās izpildes laikā. Tīrīšanas uzvedība ir dizaina daļa, tāpēc novērojiet to, nevis pieņemiet.

Pastāvīgais stāvoklis pieder vietai ar atbilstošu mūžu, jo izpildlaika direktorija ir paredzēta pazušanai. Izvēlieties vietu pēc mūža, nevis pēc ērtības. Šis ieradums novērš nākamo šī paša izmeklēšanas versiju.