Mengapa hook OpenVPN tidak menemukan file di sebelah skripnya

Hook yang berjalan tanpa kesalahan tetapi tetap melaporkan file yang hilang biasanya melihat di tempat yang salah, bukan gagal dalam tugasnya. Jalur relatif dalam skrip diselesaikan terhadap direktori kerja proses, dan layanan dimulai dengan direktori kerja yang tidak Anda pilih. File di sebelah skrip dan file yang dibuka proses hanya sama ketika sesuatu menjangkarnya. Celah itu menjelaskan sebagian besar kegagalan hook yang salah dibaca sebagai masalah izin.

Periksa jalurnya sebelum izin, karena kesalahan izin pada file yang salah tetap file yang salah.

Jalur relatif diselesaikan terhadap proses, bukan terhadap file

Ketika skrip memanggil open("policy.json"), kernel menyelesaikan nama terhadap direktori kerja proses saat ini. Tidak ada bagian dari lokasi skrip itu sendiri yang ikut dalam pencarian itu. OpenVPN memulai hook dari direktori yang ia pilih sendiri, dan opsi cd dapat mengubahnya, sehingga skrip yang diuji manual dari foldernya sendiri berperilaku berbeda begitu daemon menjalankannya. Uji manual lolos, jalannya layanan gagal, dan baris log hanya menyebut nama yang hilang.

Python mengekspos lokasi skrip sebagai __file__, dan itulah yang memungkinkan penjangkaran. Path(__file__).resolve().parent / "policy.json" membangun jalur dari file, bukan dari proses. Satu baris itu menghapus ketergantungan pada direktori kerja tanpa mengubah apa pun soal hak istimewa.

Jangkarkan jalurnya dengan sengaja, lalu periksa apa yang dilakukan resolve

resolve() mengikuti tautan simbolik, jadi instalasi yang menautkan hook ke tempatnya menjangkar pada target tautan, bukan pada direktori yang memuat tautan itu. Itu biasanya yang Anda inginkan untuk penerapan berversi, dan itu salah untuk tata letak yang mengharapkan data di samping tautan simbolik. Putuskan mana yang dimaksud penerapan, dan tulis kode yang sesuai alih-alih menemukan perbedaannya di produksi. Path(__file__).parent tanpa resolve() mempertahankan direktori milik tautan itu sendiri.

Jika data milik instans dan bukan program, ambil jalur absolut dari konfigurasi. Mengodekan lokasi secara keras mengikat hook ke satu tata letak host.

Lalui empat batas secara berurutan

Mulai dari direktori kerja: bandingkan WorkingDirectory, opsi cd OpenVPN, dan pembungkus apa pun yang mengganti direktori sebelum exec. Lalu pastikan lokasi yang diselesaikan, karena file bernama serupa di penerapan lain dapat menjawab pencarian dan menyembunyikan kesalahan. Berikutnya adalah pandangan sistem file: chroot atau ruang nama mount layanan dapat membuat jalur host absolut sekadar tidak ada. Terakhir adalah identitas akses, yang merupakan pertanyaan terpisah dari keterlihatan.

ProtectHome dan PrivateTmp menyembunyikan lokasi berbeda, dan tidak satu pun muncul dalam daftar direktori yang diambil dari host. Jalur yang ada bagi root di shell bisa tidak terlihat di dalam ruang nama unit, dan itulah sebabnya menguji perintah yang sama di luar layanan membuktikan begitu sedikit.

Perbaiki pencariannya tanpa memperlebar layanan

Menjangkarkan jalur hanya menyelesaikan batas pertama. Itu tidak menyingkap direktori yang disembunyikan layanan, dan tidak memberi akun tanpa hak istimewa akses ke file yang hanya untuk root. Menaikkan script-security mengubah skrip mana yang akan dijalankan OpenVPN; itu tidak berpengaruh pada tempat nama relatif diselesaikan. Mengubah direktori kerja untuk seluruh layanan lebih luas daripada masalahnya, karena setiap jalur relatif sertifikat, log, atau pembantu lainnya ikut berpindah.

Utamakan perbaikan sempit: jalur deterministik dalam skrip, nilai konfigurasi eksplisit untuk data instans, dan kepemilikan file yang cocok dengan akun tempat hook benar-benar berjalan.

Catat bukti yang menyebut batasnya

Laporan kegagalan yang berguna memuat tiga hal: jalur tepat yang dicoba hook, lingkungan yang menghasilkannya, dan batas mana yang menolak. Cetak jalur yang diselesaikan dan pengecualiannya tanpa menumpahkan isi file. Tritunggal itu memisahkan jangkar yang salah dari mount tersembunyi dan dari penolakan izin, yang merupakan tiga perbaikan berbeda.

Klaim bahwa root dapat membaca file dari terminal menjawab salah satu pertanyaan itu dan tidak satu pun dari yang lain. Ujilah dari konteks layanan itu sendiri.