Kial OpenVPN-hoko ne trovas la dosieron apud sia skripto

Hokoj, kiuj ruliĝas sen eraro kaj tamen raportas mankantan dosieron, kutime rigardas en la malĝusta loko, ne malsukcesas sian taskon. Relativaj vojoj en skripto solviĝas rilate al la labordosierujo de la procezo, kaj servo startas kun labordosierujo, kiun vi ne elektis. La dosiero apud la skripto kaj la dosiero, kiun la procezo malfermas, estas la sama afero nur kiam io ankras ilin. Tiu breĉo klarigas grandan parton de hokaj paneoj, kiuj estas mislegataj kiel permesaj problemoj.

Kontrolu la vojon antaŭ la permesoj, ĉar permesa eraro sur la malĝusta dosiero restas la malĝusta dosiero.

Relativa vojo solviĝas rilate al la procezo, ne al la dosiero

Kiam skripto vokas open("policy.json"), la kerno solvas la nomon rilate al la nuna labordosierujo de la procezo. Nenio el la propra loko de la skripto partoprenas tiun serĉon. OpenVPN startigas hokojn el dosierujo, kiun ĝi mem elektas, kaj la opcio cd povas ŝanĝi ĝin, do skripto testita mane el sia propra dosierujo kondutas alie, kiam la demono rulas ĝin. La mana testo sukcesas, la serva rulado malsukcesas, kaj la protokola linio mencias nur la mankantan nomon.

Python elmontras la lokon de la skripto kiel __file__, kaj tio ebligas ankradon. Path(__file__).resolve().parent / "policy.json" konstruas vojon el la dosiero anstataŭ el la procezo. Tiu unu linio forigas la dependecon de la labordosierujo sen ŝanĝi ion pri privilegioj.

Ankru la vojon intence, poste kontrolu, kion faras resolve

resolve() sekvas simbolajn ligilojn, do instalado, kiu ligas la hokon en sian lokon, ankras ĉe la celo de la ligilo, ne ĉe la dosierujo tenanta la ligilon. Tio kutime estas la dezirata por versiigita lanĉo, kaj ĝi estas malĝusta por aranĝo, kiu atendas datumojn apud la simbola ligilo. Decidu, kiun la lanĉo celas, kaj skribu la kodon kongrua anstataŭ malkovri la diferencon en produkto. Path(__file__).parent sen resolve() konservas la propran dosierujon de la ligilo.

Se la datumoj apartenas al la instanco kaj ne al la programo, prenu absolutan vojon el la agordo. Malmoligi lokon ligas la hokon al unu gastiga aranĝo.

Trairu kvar limojn laŭ ordo

Komencu per la labordosierujo: komparu la WorkingDirectory, la opcion cd de OpenVPN kaj ajnan envolvilon, kiu ŝanĝas dosierujon antaŭ exec. Poste konfirmu la solvitan lokon, ĉar samnoma dosiero en alia lanĉo povas respondi la serĉon kaj kaŝi la eraron. Sekvas la dosiersistema vido: chroot aŭ muntada nomspaco de la servo povas simple igi absolutan gastigan vojon foresta. Laste estas la alira identeco, kiu estas demando aparta de videbleco.

ProtectHome kaj PrivateTmp kaŝas malsamajn lokojn, kaj neniu el ili aperas en dosieruja listo prenita de la gastiganto. Vojo, kiu ekzistas por root en ŝelo, povas esti nevidebla interne de la nomspaco de la unuo, kaj tial testi la saman komandon ekster la servo pruvas tiel malmulte.

Riparu la serĉon sen larĝigi la servon

Ankri la vojon solvas nur la unuan limon. Ĝi ne malkaŝas dosierujon, kiun la servo kaŝas, kaj ĝi ne donas al senprivilegia konto aliron al dosiero nur por root. Pliigi script-security ŝanĝas, kiujn skriptojn OpenVPN rulos; ĝi havas neniun efikon al tio, kie relativa nomo solviĝas. Ŝanĝi la labordosierujon por la tuta servo estas pli larĝa ol la problemo, ĉar ĉiu alia relativa atestila, protokola aŭ helpa vojo moviĝas kun ĝi.

Preferu la mallarĝan riparon: determinisma vojo en la skripto, eksplicita agorda valoro por instancaj datumoj, kaj dosiera posedo kongrua kun la konto, sub kiu la hoko efektive ruliĝas.

Registru pruvojn, kiuj nomas la limon

Utila panea raporto enhavas tri aferojn: la precizan vojon, kiun la hoko provis, la medion, kiu produktis ĝin, kaj kiun limon rifuzis. Presu la solvitan vojon kaj la escepton sen elverŝi la enhavon de la dosiero. Tiu triopo apartigas malĝustan ankron de kaŝita muntado kaj de permesa rifuzo, kiuj estas tri malsamaj riparoj.

La aserto, ke root povas legi la dosieron el terminalo, respondas unu el tiuj demandoj kaj neniun el la aliaj. Testu anstataŭe el la propra kunteksto de la servo.