LD_LIBRARY_PATH sa Linux: tamang paggamit, mga panganib, at mga alternatibo

Informatec Digital » Mga Mapagkukunan » LD_LIBRARY_PATH sa Linux: wastong paggamit, mga panganib at mga alternatibo

Ang LD_LIBRARY_PATH ay isa sa mga Linux environment variable na makikita ng lahat sa kalaunan, ngunit kakaunti lamang ang nakakaintindi nito, at higit sa lahat, madalas itong ginagamit nang mali. Kapag nahihirapan ka sa mga shared library, mga executable na ayaw magsimula, o mga application na nangangailangan ng sarili nilang library, paulit-ulit na lumalabas ang pangalang ito.

Sa artikulong ito, susuriin natin kung ano ang LD_LIBRARY_PATH, kung paano gumagana ang dynamic loader sa loob , kailan mas mainam gamitin ang variable na ito, at kailan pinakamahusay na iwasan ito. Titingnan natin ang mga praktikal na halimbawa sa mga distribusyon tulad ng Ubuntu (bagaman naaangkop ito sa halos anumang distro), ipapaliwanag kung paano ito i-configure nang tama, at susuriin din ang mas malinis at mas ligtas na mga alternatibo sa permanenteng pagkakabit ng variable na ito sa iyong user profile.

Ano ang LD_LIBRARY_PATH at para saan talaga ito ginagamit?

Sa mga modernong sistema ng GNU/Linux, karamihan sa mga programa ay nakakonekta sa mga shared library (mga .so file) na nilo-load sa memorya kapag sinimulan mo ang executable. Ang component na responsable sa paghahanap ng mga library na ito sa runtime ay ang dinamikong charger (kadalasan ld.so o mga baryasyon tulad ng ld-linux-x86-64.so.2 ayon sa arkitektura).

Ang variable ng kapaligiran Tinutukoy ng LD_LIBRARY_PATH ang isang listahan ng mga direktoryo kung saan hahanapin ng dynamic loader ang mga shared library na iyon kapag inilunsad ang isang programa. Ito ay isang listahang pinaghihiwalay ng colon, parang /ruta/uno:/ruta/dos:/otra/rutaat ito ay kinokonsulta bago ang mga karaniwang ruta ng sistema bilang /lib o /usr/lib.

Nangangahulugan ito na kung ang isang library sa LD_LIBRARY_PATH ay may parehong pangalan sa isa pang library sa isang direktoryo ng system, uunahin ng loader ang library sa LD_LIBRARY_PATH . Iyan ang makapangyarihang bahagi... at siya ring ugat ng maraming problema kapag ginamit nang hindi maingat.

Ang mekanismong ito ay lalong kapaki-pakinabang kapag nagtatrabaho sa mga hindi karaniwang path ng library , halimbawa mga kapaligirang parang Nix, mga instalasyon sa mga direktoryo ng user, mga pasadyang bersyon ng mga library, o mga application na naka-package na may sarili nilang mga dependency na ayaw kumuha mula sa mga system library.

Mga karaniwang kaso ng paggamit para sa LD_LIBRARY_PATH

Ang paggamit ng LD_LIBRARY_PATH ay may katuturan sa mga partikular at kontroladong sitwasyon . Kung mananatili ka sa mga kasong ito, isa itong napaka-kapaki-pakinabang na tool; kung gagawin mo itong default na solusyon para sa lahat ng bagay, maya-maya ay may magbabalik sa dati.

Isa sa mga pinakakaraniwang gamit ay ang subukan ang isang bagong bersyon ng isang nakabahaging library laban sa isang paunang na-compile na application, nang hindi inaapektuhan ang mga system library. Halimbawa, kung lumikha ka ng isang development version ng libmylib.so Sa iyong home directory, maaari mong isaayos ang LD_LIBRARY_PATH upang tanging ang iyong test session lamang ang gagamit nito.

Isa pang karaniwang senaryo ay ang paglilipat ng mga library upang mapanatili ang mga lumang bersyon . Isipin na gusto mong panatilihin ang isang mas lumang bersyon ng isang library para sa isang legacy application, habang ang natitirang bahagi ng system ay gumagamit ng mas bagong bersyon; gamit ang LD_LIBRARY_PATH maaari mong idirekta ang partikular na application na iyon sa direktoryo kung saan mo iniimbak ang mas lumang bersyon.

Madalas din itong ginagamit upang mag-set up ng mga self-contained at relocatable na kapaligiran para sa malalaking aplikasyon, kung saan ang vendor ay nag-iimpake ng sarili nitong mga library sa loob ng isang folder, nang hindi umaasa sa mga system library. Sa mga kasong ito, karaniwang mayroong isang startup script na nag-aayos ng LD_LIBRARY_PATH upang ang aplikasyon ay palaging naglo-load ng sarili nitong mga .so file.

Sa lahat ng mga kasong ito, ang susi ay ang LD_LIBRARY_PATH ay ginagamit sa isang limitado at tiyak na paraan , na nauugnay sa isang partikular na aplikasyon o isang kapaligiran sa pagsubok, hindi bilang isang pandaigdigang variable na nakakaapekto sa lahat ng pinapatakbo ng isang gumagamit o sa buong sistema.

Paano i-configure ang LD_LIBRARY_PATH sa Linux nang paunti-unti

Kahit alam mo ang mga panganib, gusto mo pa rin tukuyin ang LD_LIBRARY_PATH sa iyong kapaligiran ng gumagamitSa mga distribusyon tulad ng Ubuntu, karaniwan ang pag-edit ng file ~/.bashrc (kung ipagpapalagay na ginagamit mo ang Bash bilang iyong default na shell). Ito ang file na tumatakbo sa tuwing magbubukas ka ng bagong interactive terminal.

Para magsimula, buksan ang file .bashrc gamit ang paborito mong editorGinagamit ito sa maraming tutorial nano Para sa pagiging simple, ngunit maaari mo ring gawin ang pareho sa vi, vim o kahit anong text editor:

nano ~ / .bashrc

Kapag nabuksan na, kailangan mong magdagdag ng export line para itakda ang variable. Ang mahalaga rito ay huwag mag-iwan ng mga espasyo sa paligid ng equals sign, kung hindi ay mali ang magiging interpretasyon nito sa Bash. Ang isang tamang halimbawa ay:

i-export ang LD_LIBRARY_PATH=/home/osboxes/mukul

Sa kasong ito, sinasabi namin sa sistema na kapag naghahanap ng mga shared library, dapat nitong isaalang-alang ang direktoryo ng /home/osboxes/mukul bago ang mga karaniwang direktoryo. Maaari mo itong palitan ng path papunta sa iyong mga custom na .so file o ng mga library na gusto mong gamitin.

Pagkatapos i-save ang mga pagbabago at lumabas sa editor, kailangan mong i-reload ang shell configuration para magkabisa ang bagong environment variable sa kasalukuyang session. Karaniwan itong ginagawa gamit ang:

pinagmulan ~ /. bashrc

Kung gusto mong suriin kung tama ang pagkakagamit ng lahat, gamitin lang ang command echo Tungkol sa variable. Ipapakita nito sa iyo ang mga path na kasalukuyang nilalaman ng LD_LIBRARY_PATH:

echo $LD_LIBRARY_PATH

Kung kasama sa output line ang direktoryong idinagdag mo, nangangahulugan ito na na-load nang tama ang configuration at isasaalang-alang na ngayon ng dynamic loader ang path na iyon kapag naglulunsad ng mga programa.

Paano magdagdag ng mga karagdagang ruta nang walang anumang nasira

Kadalasan, hindi mo gugustuhing ganap na palitan ang mga nilalaman ng LD_LIBRARY_PATH , sa halip ay magdagdag ng isa pang path habang pinapanatili ang mga umiiral na. Mahalaga ito kung ang ibang mga library ay na-configure na at ayaw mong masira ang mga dependency sa ibang mga application.

Para "kadenahin" ang mga ruta, isang uri ng pag-export ang karaniwang ginagamit na magdagdag ng bagong direktoryo bago ang nakaraang variableHalimbawa, kung gusto mong idagdag /home/osboxes/sample Sa kung ano ang natukoy na, maaari kang magsulat ng ganito sa iyong .bashrc:

i-export ang LD_LIBRARY_PATH=/home/osboxes/sample:${LD_LIBRARY_PATH}

Mahalaga ang pagkakasunod-sunod dahil ang dynamic loader ay unang maghahanap sa /home/osboxes/sample at pagkatapos ay sa iba pang mga direktoryo kung saan umiiral na ang variable. Pinapayagan ka nitong magsama ng isang priority library para lamang sa ilang mga pagsubok, na iniiwan ang natitirang bahagi ng configuration na hindi nagagalaw.

Pagkatapos baguhin ang file, tandaan muli isagawa ang utos na "pinagmulan" sa ~/.bashrc para ilapat ang mga pagbabago sa kasalukuyang terminal, at suriin muli gamit ang echo $LD_LIBRARY_PATH na ang bagong ruta ay lumalabas sa itaas ng listahan.

Inirerekumenda ito iwasan ang patuloy na pagbabago sa LD_LIBRARY_PATHAng bawat hindi maayos na naisagawang pagbabago ay maaaring makaapekto sa mga programang hindi mo maiisip. Gamitin ang pattern na "add" kasama ang syntax. ${LD_LIBRARY_PATH} Nakakatulong ito na mapanatili ang pagkakapare-pareho, ngunit mas mainam na huwag itong gamitin nang labis.

Paano gumagana ang paghahanap sa aklatan at kung bakit ito maaaring mapanganib

Sa likod ng LD_LIBRARY_PATH mayroong isang napaka-espesipikong pag-uugali ng dynamic loader: prayoridad sa paghahanapAng mga path na ilalagay mo sa variable na ito ay pinoproseso bago ang mga paunang na-compile na path at mga karaniwang direktoryo ng iyong system, tulad ng /lib, /usr/lib o /usr/lib64.

Lumilitaw ang problema kapag ang mga karagdagang direktoryong ito ay naglalaman ng isang library na may parehong pangalan gaya ng isang system library, ngunit may iba o hindi tugmang bersyon. Walang pag-aatubiling pipiliin ng dynamic loader ang unang library na matatagpuan nito sa LD_LIBRARY_PATH, kahit na ang application ay orihinal na naka-link sa ibang bersyon.

Ang sitwasyong ito ay nagbubukas ng pinto sa ilang uri ng mga conflict, kabilang ang isang medyo seryosong conflict sa seguridad . Kung ang isang malisyosong user ay makapagpatakbo sa iyo ng isang programa na may minanipulang LD_LIBRARY_PATH, may posibilidad na ang isang malisyosong library ay maaaring makalusot at palitan ang lehitimong bersyon, na magpapatupad ng hindi gustong code.

Dahil dito, karaniwang binabalewala ng mga binary ng setuid o setgid ang LD_LIBRARY_PATH nang lubusan. Dahil tumatakbo ang mga ito nang may mataas na pribilehiyo, ang pagtanggap ng mga arbitrary path mula sa kapaligiran ng gumagamit ay magiging isang malaking panganib; itinatapon na lamang ng sistema ang variable na iyon sa mga kasong ito.

Bukod sa seguridad, mayroong isang aspeto ng pagganap at kahusayan Isang bagay na dapat tandaan. Ang bawat direktoryo na idinaragdag mo sa LD_LIBRARY_PATH ay pinipilit ang loader na subukang magbukas ng mga library sa path na iyon kahit na wala naman talaga ang mga ito roon. Nagreresulta ito sa maraming bigong tawag sa open()na nagbabalik ng "ENOENT (Walang ganoong file o direktoryo)" at nagpapabagal sa pagsisimula ng mga aplikasyon.

Kung mas maraming path ang idadagdag mo, lalo na kung ang mga ito ay mga remote directory (NFS) , mas maaapektuhan ang oras ng pagsisimula ng iyong mga programa at mas malaki ang load sa file system. Sa malalaking kapaligiran na may daan-daang user, ang labis na paggamit ng LD_LIBRARY_PATH ay maaaring maging isang hindi inaasahang bottleneck.

Karaniwang mga problema: mga hindi pagkakapare-pareho at mga nakatagong dependency

Ang isa pang karaniwang epekto ay ang hindi pagkakapare-pareho sa pagitan ng mga binary at library . Maaaring pilitin ng LD_LIBRARY_PATH ang isang programa na mag-load ng ibang bersyon ng isang library kaysa sa naka-link dito, at hindi sila palaging 100% tugma sa ABI o antas ng pag-uugali.

Sa pinakamaganda, kung mayroong malinaw na hindi pagkakatugma, ang application ay mabibigong magsimula o mabilis na mag-crash, na mag-iiwan ng mga halatang bakas ng problema. Ngunit ang tunay na mapanganib ay kapag ang library ay "halos gumagana," ngunit pagkatapos ay nagsisimulang magbalik ng mga maling resulta o kumilos nang medyo naiiba, na sapat na banayad upang maging mahirap i-debug.

Isang partikular na problematikong sitwasyon ng paggamit ay ang pagtukoy sa LD_LIBRARY_PATH sa buong mundo sa mga profile ng user o, mas malala pa, sa profile ng system. Kapag nangyari ito, lahat ng application na tumatakbo sa session na iyon ay makikita sa configuration na iyon, kahit na ang mga hindi kailanman idinisenyo upang gumana sa mga karagdagang path na iyon.

Kapag nagbago o tumigil na sa pag-iral ang mga pandaigdigang rutang iyon, maraming binary ang maaaring biglang tumigil sa paggana dahil, nang walang nakakapansin, nagsimula na silang umasa sa "patch" na iyon ng LD_LIBRARY_PATH upang mahanap ang kanilang mga library.

Ito ang nagpapaliwanag kung bakit sa maraming propesyonal na kapaligiran ay labis na binibigyang-diin ang paggamit ng variable bilang isang minsanang tool sa pagsubok o solusyon sa emerhensya , hindi kailanman bilang isang pangmatagalang matatag na mekanismo ng configuration.

Paano makita kung aling mga library ang aktwal na ginagamit

Para lubos na maunawaan kung paano nakakaapekto ang iyong mga pagbabago sa LD_LIBRARY_PATH, mahalagang malaman kung aling mga library ang ginagamit ng bawat isa para maipapatupadDito matatagpuan ang mga utos tulad ng lddna nagbibigay ng medyo malinaw na pananaw sa dynamic linking.

Ipinapakita ng utos na `ldd` , para sa isang partikular na binary, kung aling mga dynamic library ang kailangan nito at mula saang path ito nilo-load. Halimbawa, kung patatakbuhin mo ang:

ldd /usr/bin/file

Makakakita ka ng listahan ng mga linya ng uri libmagic.so.1 => /usr/lib64/libmagic.so.1, kasama ang resolusyon ng linux-vdso.so.1, libc.so.6 at ang dynamic charger mismo. Ang impormasyong ito ay nagbibigay sa iyo ng larawan pa rin ng mga pangunahing dependency ng executable.

Gayunpaman, may mga pagkakataon kung saan ang isang shared library naglo-load ng iba pang mga library habang tumatakbo (halimbawa, sa pamamagitan ng dlopen()), at ang mga ito ay hindi makikita sa output ng ldd. Upang makita ang mas kumpletong larawan, kinakailangang suriin kung aling mga .so file ang aktwal na naka-map sa address space ng isang tumatakbong proseso.

Sa ilang sistemang parang Solaris, mayroong utos na `pldd` na naglilista ng mga dynamic library na nilo-load ng isang proseso batay sa PID nito. Kapag ginamit sa isang programang tulad ng Bash, makikita mo kung paano pinagsasama ng iba ang mga library na nakalista ng `ldd`, tulad ng mga character conversion module o mga NSS module para sa resolusyon ng user at grupo.

Sa purong Linux, ang pldd ay hindi laging magagamit bilang isang karaniwang binary, ngunit May mga script sa Perl o iba pang mga tool na kumukuha ng impormasyon mula sa /proc/<PID>/mapsnakakamit ang katulad na epekto. Sa ganitong paraan, masusuri mo kung ang iyong mga setting ng LD_LIBRARY_PATH ay naging sanhi ng pag-load ng mga hindi inaasahang library.

Mas malinis na paraan para maiwasan ang pag-asa sa LD_LIBRARY_PATH

Ang pangkalahatang rekomendasyon kapag sinimulan mong mag-ipon ng mga workaround gamit ang LD_LIBRARY_PATH ay simple: gamitin ito nang kaunti hangga't maaari . Ang bawat path na idinaragdag mo ay maaaring maging sanhi ng mga error, conflict sa bersyon, at mga isyu sa pagganap, kaya sulit na isaalang-alang ang mas matatag na mga alternatibo.

Kung iko-compile mo ang iyong mga aplikasyon (halimbawa, sinusundan ang Linux From Scratch ), maaari mong gamitin ang opsyong `-rpath` ng linker . Binibigyang-daan ka ng opsyong ito na i-embed ang path papunta sa mga library na pinagbabasehan ng executable nang direkta sa executable, para malaman ng binary kung saan hahanapin ang mga ito nang hindi kinakailangang baguhin ang mga global environment variable.

Ang isang tipikal na halimbawa ay magiging ganito:

cc -o myprog obj1.o … objn.o -Wl,-rpath=/path/to/lib -L/path/to/lib -lmylib

Gamit ito, idinaragdag ng linker /path/to/lib papunta sa runpath ng executableKung kailangan mo ng maraming ruta, medyo maginhawang gamitin ang environment variable. LD_RUN_PATHna naiintindihan din ng linker at maaari mong lagyan ng listahan ng mga direktoryo na pinaghihiwalay ng mga tutuldok.

Maaari mong gawin, halimbawa:

i-export ang LD_RUN_PATH=/landas/papunta/lib1:/landas/papunta/lib2:/landas/papunta/lib3
cc -o myprog obj1.o … objn.o -L/path/to/lib1 -lmylib1 -L/path/to/lib2 -lmylib2

Pagkatapos ng pag-compile, maaari mong suriin sa ldd na ang binary Tama nitong nireresolba ang lahat ng mga library nito nang hindi umaasa sa LD_LIBRARY_PATH. Kung may lumitaw na anumang error na "not found", kailangan mong suriin ang Makefile at ang configuration ng LD_RUN_PATH.

Kapag hindi ka makapag-recompile, maaari kang gumamit ng mga tool tulad ng chrpath upang baguhin ang runpath na naka-embed na sa executable. May mga limitasyon ang pamamaraang ito: maaari mo lamang i-overwrite ang umiiral na string, hindi ito palawigin, at kung ang binary ay walang tinukoy na runpath, walang dapat baguhin.

Paggamit ng mga wrapper script at paggawa ng mga partikular na pagsasaayos mula sa command line

Kung hindi opsyon ang pag-link gamit ang -rpath o chrpath, maaari ka pa ring gumamit ng mga wrapper script na nag-aayos ng LD_LIBRARY_PATH para lamang sa isang partikular na aplikasyon at wala nang iba pa. Ito ay isang hindi gaanong mapanghimasok na pamamaraan kumpara sa pakikialam sa profile ng user.

Ang isang karaniwang pambalot sa shell ay magiging ganito ang hitsura:

#! / Bin / SH
LD_LIBRARY_PATH=/landas/papunta/lib1:/landas/papunta/lib2:/landas/papunta/lib3
i-export ang LD_LIBRARY_PATH
exec /path/to/bin/myprog «$@»

Sa pamamaraang ito, ang environment variable ay "nakokontamina" lamang para sa myprog at, bilang karagdagan, para sa anumang child process na inilulunsad nito, ngunit hindi para sa anumang iba pang mga command na iyong isinasagawa sa iyong session. Ito ay isang ganap na katanggap-tanggap na solusyon kapag napipilitan kang magtrabaho sa mga partikular na bersyon ng library para sa isang partikular na application.

Isa pang kapaki-pakinabang na opsyon para sa mabilisang pagsubok ay ang paggamit ng utos na `env` upang tukuyin ang `LD_LIBRARY_PATH` para lamang sa isang pagpapatupad. Halimbawa:

env LD_LIBRARY_PATH=/landas/papunta/lib1:/landas/papunta/lib2 ./myprog

Sa ganitong paraan, inilalapat ang baryabol sa panawagan lamang na iyon de myprogAt kapag tapos na ito, ang iyong shell ay maiiwang buo, nang walang bakas ng mga kakaibang landas na maaaring makaapekto sa susunod na utos na iyong patakbuhin.

Ang mahigpit na inirerekomendang iwasan ay ang paggawa ng mga bagay tulad ng:

i-export ang LD_LIBRARY_PATH=/landas/papunta/lib1:/landas/papunta/lib2
./myprog

Ang pattern na iyon ay nag-iiwan ng LD_LIBRARY_PATH tinukoy para sa lahat ng kasunod na mga order na ilulunsad mo mula sa terminal na iyon, na maaaring magdulot ng mga side effect na napakahirap subaybayan sa ibang pagkakataon. Para sa mga nakahiwalay na pagsubok, ang tawag na may env Mas malinis ito.

Mabuting gawi at karaniwang pagkakamali na dapat iwasan

Isang malawakang tinatanggap na ginintuang rekomendasyon ay Huwag kailanman tukuyin ang LD_LIBRARY_PATH sa mga profile sa pag-loginhindi mga file ng user o system. Sa madaling salita, iwasang idagdag ito sa mga file tulad ng ~/.bash_profile, ~/.profile, /etc/profile o katulad.

Kapag ang ganitong sensitibong variable ay nakatakda sa buong mundo, lahat ng application na inilunsad ng user na iyon ay gagamit ng mga karagdagang path na iyon, kahit na ang mga perpektong na-configure upang gumana sa mga system library. Ang paghihigpit sa saklaw nito sa mga partikular na script o minsanang pagpapatupad ay palaging isang mas ligtas na pamamaraan.

Makabubuting maging maingat din sa mga third-party installer na, habang nag-i-install, ay hihilingin sa iyo na idagdag ang LD_LIBRARY_PATH sa iyong profile o kung sino ang gagawa nito para sa iyo sa buong mundo. Sa karamihan ng mga kaso, ito ay isang madaling shortcut para sa provider, ngunit magdudulot ito ng mga problema para sa iyong kapaligiran sa katamtamang termino.

Hangga't maaari, sulit na makipaglaban nang mas maigi at maghanap ng mga malilinis na alternatibo : pagsasaayos ng runpath ng executable, pag-install ng mga library sa isang karaniwang direktoryo, paggamit ng mga modernong mekanismo ng packaging, o pagbalot ng app gamit ang isang script wrapper sa halip na hawakan ang pangkalahatang kapaligiran.

Kung mapipilitan kang gamitin ang variable, subukang panatilihing maigsi at tiyak ang mga path hangga't maaari, bawasan ang bilang ng mga direktoryo, at iwasan ang mga path na matatagpuan sa mga remote file system anuman ang mangyari maliban kung mahigpit na kinakailangan.

Dahil sa lahat ng ito, ang LD_LIBRARY_PATH ay nananatiling isang makapangyarihan ngunit maselang kagamitan : ito ay lubhang kapaki-pakinabang para sa pagsubok ng mga bagong bersyon ng library, paglilipat ng mga lumang .so file, o pagbuo ng mga self-contained na kapaligiran para sa malalaking aplikasyon, ngunit ang walang pinipiling paggamit nito ay may dalang mga panganib sa seguridad, mga problema sa pagganap, at mga hindi pagkakapare-pareho na mahirap i-debug. Ang pag-unawa kung paano gumagana ang dynamic loader, pag-asa sa mga alternatibo tulad ng -rpath, LD_RUN_PATH, o mga wrapper script, at paglilimita sa variable na ito sa mga partikular na konteksto ang pinakamahusay na paraan upang samantalahin ang LD_LIBRARY_PATH nang hindi ito ginagawang isang patibong para sa iyong system.