OpenVPN હૂક પોતાની સ્ક્રિપ્ટની બાજુમાંની ફાઇલ કેમ શોધી શકતો નથી

ભૂલ વિના ચાલે અને તોપણ ખૂટતી ફાઇલની જાણ કરે એવા હૂક સામાન્ય રીતે ખોટી જગ્યાએ જુએ છે, તેમના કામમાં નિષ્ફળ જતા નથી. સ્ક્રિપ્ટમાંની સાપેક્ષ પાથ પ્રક્રિયાના કાર્યકારી ડિરેક્ટરીની સાપેક્ષે ઉકેલાય છે, અને સેવા એવી કાર્યકારી ડિરેક્ટરી સાથે શરૂ થાય છે જે તમે પસંદ કરી નથી. સ્ક્રિપ્ટની બાજુમાંની ફાઇલ અને પ્રક્રિયા જે ફાઇલ ખોલે છે તે ત્યારે જ એક જ વસ્તુ છે જ્યારે કંઈક તેમને એન્કર કરે. એ જ તફાવત હૂક નિષ્ફળતાઓના મોટા ભાગને સમજાવે છે જે ખોટી રીતે પરવાનગીની સમસ્યા તરીકે વાંચવામાં આવે છે.

પરવાનગીઓ પહેલાં પાથ ચકાસો, કારણ કે ખોટી ફાઇલ પરની પરવાનગી ભૂલ હજી પણ ખોટી ફાઇલ છે.

સાપેક્ષ પાથ ફાઇલની નહીં, પ્રક્રિયાની સાપેક્ષે ઉકેલાય છે

જ્યારે સ્ક્રિપ્ટ open("policy.json") ને કૉલ કરે છે, ત્યારે કર્નલ નામને પ્રક્રિયાની વર્તમાન કાર્યકારી ડિરેક્ટરીની સાપેક્ષે ઉકેલે છે. સ્ક્રિપ્ટના પોતાના સ્થાનનું કંઈ પણ એ શોધમાં ભાગ લેતું નથી. OpenVPN પોતે પસંદ કરેલી ડિરેક્ટરીથી હૂક શરૂ કરે છે, અને cd વિકલ્પ તેને બદલી શકે છે, તેથી પોતાના ફોલ્ડરથી હાથે ચકાસાયેલી સ્ક્રિપ્ટ ડીમન તેને ચલાવે ત્યારે અલગ રીતે વર્તે છે. હાથની કસોટી પાસ થાય છે, સેવા ચલાવવાનું નિષ્ફળ જાય છે, અને લોગની લાઇન ફક્ત ખૂટતું નામ જણાવે છે.

Python સ્ક્રિપ્ટનું સ્થાન __file__ તરીકે બહાર કાઢે છે, અને એ જ એન્કરિંગ શક્ય બનાવે છે. Path(__file__).resolve().parent / "policy.json" પ્રક્રિયામાંથી નહીં, ફાઇલમાંથી પાથ બનાવે છે. એ એક લાઇન વિશેષાધિકારોમાં કંઈ બદલ્યા વિના કાર્યકારી ડિરેક્ટરીની અવલંબન દૂર કરે છે.

પાથને જાણી જોઈને એન્કર કરો, પછી resolve શું કરે છે તે ચકાસો

resolve() સિમ્બોલિક લિંક્સને અનુસરે છે, તેથી હૂકને તેની જગ્યાએ લિંક કરતી સ્થાપના લિંકના લક્ષ્ય પર એન્કર થાય છે, લિંક ધરાવતી ડિરેક્ટરી પર નહીં. વર્ઝનવાળી ડિપ્લોયમેન્ટ માટે સામાન્ય રીતે આ જ જોઈએ છે, અને સિમ્બોલિક લિંકની બાજુમાં ડેટા ધારતી ગોઠવણી માટે તે ખોટું છે. ડિપ્લોયમેન્ટ કઈ રીતે અર્થ ધરાવે છે તે નક્કી કરો અને પ્રોડક્શનમાં તફાવત શોધવાને બદલે તે મુજબ કોડ લખો. Path(__file__).parent વિના resolve() લિંકની પોતાની ડિરેક્ટરી રાખે છે.

જો ડેટા પ્રોગ્રામનો નહીં, ઇન્સ્ટન્સનો હોય, તો કન્ફિગરેશનમાંથી નિરપેક્ષ પાથ લો. સ્થાન હાર્ડકોડ કરવું હૂકને એક હોસ્ટ ગોઠવણી સાથે બાંધે છે.

ચાર સીમાઓ ક્રમમાં પાર કરો

કાર્યકારી ડિરેક્ટરીથી શરૂ કરો: યુનિટની WorkingDirectory, OpenVPNનો cd વિકલ્પ અને exec પહેલાં ડિરેક્ટરી બદલતા કોઈપણ રેપરની સરખામણી કરો. પછી ઉકેલાયેલું સ્થાન પુષ્ટિ કરો, કારણ કે બીજી ડિપ્લોયમેન્ટમાં સમાન નામની ફાઇલ શોધનો જવાબ આપી ભૂલ છુપાવી શકે છે. પછી ફાઇલસિસ્ટમનું દૃશ્ય આવે છે: chroot અથવા સેવાનું માઉન્ટ નેમસ્પેસ હોસ્ટનો નિરપેક્ષ પાથ સહેલાઈથી ગેરહાજર કરી શકે છે. અંતે ઍક્સેસ ઓળખ છે, જે દૃશ્યતાથી અલગ પ્રશ્ન છે.

ProtectHome અને PrivateTmp જુદાં જુદાં સ્થાન છુપાવે છે, અને બંમાંથી એક પણ હોસ્ટમાંથી લીધેલી ડિરેક્ટરી યાદીમાં દેખાતું નથી. શેલમાં root માટે અસ્તિત્વમાં હોય એવો પાથ યુનિટના નેમસ્પેસની અંદર અદૃશ્ય હોઈ શકે છે, અને તેથી સેવાની બહાર એ જ આદેશ ચકાસવો ખૂબ ઓછું સાબિત કરે છે.

સેવા વિસ્તાર્યા વિના શોધ સુધારો

પાથ એન્કર કરવો ફક્ત પ્રથમ સીમા ઉકેલે છે. તે સેવા છુપાવે છે એવી ડિરેક્ટરી ખુલ્લી કરતું નથી, અને તે અનધિકારિત ખાતાને ફક્ત root માટેની ફાઇલમાં ઍક્સેસ આપતું નથી. script-security વધારવું એ બદલે છે કે OpenVPN કઈ સ્ક્રિપ્ટ ચલાવશે; સાપેક્ષ નામ ક્યાં ઉકેલાય છે તેના પર તેની કોઈ અસર નથી. આખી સેવા માટે કાર્યકારી ડિરેક્ટરી બદલવી સમસ્યા કરતાં વધુ વિશાળ છે, કારણ કે બીજો દરેક સાપેક્ષ પ્રમાણપત્ર, લોગ કે સહાયક પાથ તેની સાથે ખસે છે.

સાંકડો સુધારો પસંદ કરો: સ્ક્રિપ્ટમાં નિર્ધારિત પાથ, ઇન્સ્ટન્સ ડેટા માટે સ્પષ્ટ કન્ફિગરેશન મૂલ્ય, અને હૂક ખરેખર જે ખાતા હેઠળ ચાલે તેના સાથે મેળ ખાતી ફાઇલ માલિકી.

સીમાનું નામ આપતા પુરાવા નોંધો

ઉપયોગી નિષ્ફળતા અહેવાલમાં ત્રણ વસ્તુ હોય છે: હૂકે પ્રયત્ન કરેલો ચોક્કસ પાથ, તેને જન્મ આપનારું વાતાવરણ, અને કઈ સીમાએ નકાર્યું. ફાઇલનો સંદર્ભ ઠાલવ્યા વિના ઉકેલાયેલો પાથ અને અપવાદ છાપો. એ ત્રણેય ખોટા એન્કરને છુપાયેલા માઉન્ટથી અને પરવાનગી નકારથી અલગ પાડે છે, અને એ ત્રણ જુદા સુધારા છે.

root ટર્મિનલથી ફાઇલ વાંચી શકે છે એ દાવો એ પ્રશ્નોમાંથી એકનો જવાબ આપે છે અને બાકીના એક પણનો નહીં. તેના બદલે સેવાના પોતાના સંદર્ભથી ચકાસો.