Miksi OpenVPN-koukku ei löydä komentosarjansa viereistä tiedostoa

Koukut, jotka toimivat virheittä ja ilmoittavat silti puuttuvan tiedoston, katsovat yleensä väärään paikkaan, eivät epäonnistu tehtävässään. Komentosarjan suhteelliset polut ratkeavat prosessin työhakemiston mukaan, ja palvelu käynnistyy työhakemistossa, jota et valinnut. Komentosarjan vieressä oleva tiedosto ja tiedosto, jonka prosessi avaa, ovat sama asia vain kun jokin ankkuroi ne. Tämä ero selittää suuren osan koukkujen epäonnistumisista, jotka luetaan virheellisesti käyttöoikeusongelmiksi.

Tarkista polku ennen käyttöoikeuksia, koska käyttöoikeusvirhe väärässä tiedostossa on yhä väärä tiedosto.

Suhteellinen polku ratkeaa prosessin, ei tiedoston mukaan

Kun komentosarja kutsuu open("policy.json"), ydin ratkaisee nimen prosessin nykyisen työhakemiston mukaan. Mikään komentosarjan omassa sijainnissa ei osallistu tähän hakuun. OpenVPN käynnistää koukut hakemistosta, jonka se itse valitsee, ja valinta cd voi muuttaa sitä, joten omasta kansiostaan käsin testattu komentosarja käyttäytyy toisin, kun daemon suorittaa sen. Käsitestaus menee läpi, palvelun suoritus epäonnistuu, ja lokirivi mainitsee vain puuttuvan nimen.

Python paljastaa komentosarjan sijainnin muodossa __file__, ja juuri se tekee ankkuroinnin mahdolliseksi. Path(__file__).resolve().parent / "policy.json" rakentaa polun tiedostosta eikä prosessista. Tämä yksi rivi poistaa työhakemistoriippuvuuden muuttamatta mitään käyttöoikeuksissa.

Ankkuroi polku tarkoituksella ja tarkista sitten, mitä resolve tekee

resolve() seuraa symbolisia linkkejä, joten asennus, joka linkittää koukun paikalleen, ankkuroituu linkin kohteeseen, ei linkin sisältävään hakemistoon. Se on yleensä se, mitä versioidussa käyttöönotossa halutaan, ja se on väärin asettelussa, joka odottaa tietoja symbolisen linkin viereen. Päätä, kumpaa käyttöönotto tarkoittaa, ja kirjoita koodi sen mukaiseksi sen sijaan, että löytäisit eron tuotannossa. Path(__file__).parent ilman resolve() säilyttää linkin oman hakemiston.

Jos tiedot kuuluvat instanssille eivätkä ohjelmalle, ota absoluuttinen polku asetuksista. Sijainnin kovakoodaus sitoo koukun yhteen isäntäasetteluun.

Käy neljä rajaa läpi järjestyksessä

Aloita työhakemistosta: vertaa yksikön WorkingDirectory, OpenVPN:n valintaa cd ja mitä tahansa käärettä, joka vaihtaa hakemiston ennen execiä. Vahvista sitten ratkennut sijainti, koska samanniminen tiedosto toisessa käyttöönotossa voi vastata hakuun ja peittää virheen. Seuraavaksi tulee tiedostojärjestelmän näkymä: chroot tai palvelun mount-nimiavaruus voi tehdä absoluuttisesta isäntäpolusta yksinkertaisesti puuttuvan. Viimeisenä on pääsyidentiteetti, joka on näkyvyydestä erillinen kysymys.

ProtectHome ja PrivateTmp piilottavat eri sijainteja, eikä kumpikaan näy isännästä otetussa hakemistolistauksessa. Polku, joka on olemassa rootille kuoressa, voi olla näkymätön yksikön nimiavaruudessa, ja siksi saman komennon testaaminen palvelun ulkopuolella todistaa niin vähän.

Korjaa haku laajentamatta palvelua

Polun ankkurointi ratkaisee vain ensimmäisen rajan. Se ei paljasta hakemistoa, jonka palvelu piilottaa, eikä anna vailla oikeuksia olevalle tilille pääsyä tiedostoon, joka on vain rootille. script-security kasvattaminen muuttaa, mitkä komentosarjat OpenVPN suorittaa; sillä ei ole vaikutusta siihen, missä suhteellinen nimi ratkeaa. Työhakemiston vaihtaminen koko palvelulle on laajempaa kuin ongelma, koska jokainen muu suhteellinen varmenteen, lokin tai apurin polku siirtyy mukana.

Suosi kapeaa korjausta: deterministinen polku komentosarjassa, eksplisiittinen asetusarvo instanssin tiedoille ja tiedoston omistajuus, joka vastaa tiliä, jonka alla koukku todella toimii.

Kirjaa todisteet, jotka nimeävät rajan

Hyödyllinen vikaraportti sisältää kolme asiaa: tarkan polun, jota koukku yritti, ympäristön, joka sen tuotti, ja mikä raja kieltäytyi. Tulosta ratkennut polku ja poikkeus kaatamatta tiedoston sisältöä. Tämä kolmikko erottaa väärän ankkurin piilotetusta mountista ja käyttöoikeuden kiellosta, jotka ovat kolme eri korjausta.

Väite, että root voi lukea tiedoston päätteeltä, vastaa yhteen näistä kysymyksistä eikä yhteenkään muista. Testaa sen sijaan palvelun omasta kontekstista.