LD_LIBRARY_PATH në Linux: përdorimi i saktë, rreziqet dhe alternativat

Informatec Digital » Burime » LD_LIBRARY_PATH në Linux: përdorimi i saktë, rreziqet dhe alternativat

LD_LIBRARY_PATH Është një nga ato variablat e mjedisit Linux që të gjithë e shohin herët a vonë, por që shumë pak njerëz e kuptojnë plotësisht dhe, mbi të gjitha, që keqpërdoret shpesh. Kur filloni të keni probleme me bibliotekat e përbashkëta, skedarët ekzekutues që nuk fillojnë ose aplikacionet që kanë nevojë për bibliotekat e tyre, ky emër shfaqet vazhdimisht.

Në këtë artikull do të shohim Çfarë është LD_LIBRARY_PATH dhe si funksionon ngarkuesi dinamik në mënyrë të brendshme?Do të shqyrtojmë se kur ka kuptim të përdoret kjo variabël dhe kur është më mirë ta shmangim atë. Do të shohim shembuj praktikë në shpërndarjet e ngjashme me Ubuntu (megjithëse është e zbatueshme në pothuajse çdo shpërndarje), do të shpjegojmë se si ta konfigurojmë atë saktë dhe gjithashtu do të shqyrtojmë alternativa shumë më të pastra dhe më të sigurta sesa përdorimi i vazhdueshëm i kësaj variabli në profilin tuaj të përdoruesit.

Çfarë është LD_LIBRARY_PATH dhe për çfarë përdoret në të vërtetë?

Në sistemet moderne GNU/Linux, shumica e programeve lidhen me bibliotekat e përbashkëta (skedarë .so) që ngarkohen në memorie kur nisni skedarin ekzekutues. Komponenti përgjegjës për gjetjen e këtyre librarive në kohën e ekzekutimit është karikues dinamik (zakonisht ld.so ose variacione të tilla si ld-linux-x86-64.so.2 sipas arkitekturës).

Variabli i mjedisit LD_LIBRARY_PATH përcakton një listë drejtorish ku ngarkuesi dinamik do të kërkojë ato biblioteka të përbashkëta kur të nisë një program. Është një listë e ndarë me dy pika, diçka si /ruta/uno:/ruta/dos:/otra/rutadhe konsultohet para rrugëve standarde të sistemit si /lib o /usr/lib.

Kjo do të thotë që nëse një bibliotekë në LD_LIBRARY_PATH ka të njëjtin emër si një bibliotekë tjetër e vendosur në një drejtori sistemi, Ngarkuesi do t'i japë përparësi atij në LD_LIBRARY_PATHPikërisht aty qëndron fuqia... dhe gjithashtu rrënja e shumë problemeve kur përdoren pa kujdes.

Ky mekanizëm është veçanërisht i dobishëm kur punoni me shtigje jo standarde të bibliotekësPër shembull, mjedise të tipit Nix, instalime në drejtoritë e përdoruesve, versione të personalizuara të bibliotekave ose aplikacione të paketuara me varësitë e tyre që nuk duan të marrin të dhëna nga bibliotekat e sistemit.

Rastet tipike të përdorimit për LD_LIBRARY_PATH

Përdorimi i LD_LIBRARY_PATH ka kuptim në skenarë shumë specifikë dhe të kontrolluarNëse i përmbahesh këtyre rasteve, është një mjet shumë i dobishëm; nëse e bën zgjidhjen tënde të parazgjedhur për gjithçka, herët a vonë diçka do të të shpërthejë në fytyrë.

Një nga përdorimet më të zakonshme është të provo një version të ri të një biblioteke të përbashkët kundër një aplikacioni të parapërgatitur, pa prekur bibliotekat e sistemit. Për shembull, nëse keni krijuar një version zhvillimi të libmylib.so Në direktorinë tuaj kryesore, mund ta rregulloni LD_LIBRARY_PATH në mënyrë që vetëm seanca juaj e testimit ta përdorë atë.

Një tjetër skenar shumë i zakonshëm është ai i zhvendosni bibliotekat për të ruajtur versionet më të vjetraImagjinoni që doni të ruani një version më të vjetër të një biblioteke për një aplikacion të trashëguar, ndërsa pjesa tjetër e sistemit përdor një version më të ri; me LD_LIBRARY_PATH mund ta drejtoni atë aplikacion specifik në direktorinë ku e ruani versionin më të vjetër.

Përdoret gjithashtu mjaft për të hipur në kalë mjedise të pavarura dhe të zhvendosshme Në aplikacione të mëdha, shitësi paketon bibliotekat e veta brenda një dosjeje, pa u mbështetur në bibliotekat e sistemit. Në këto raste, zakonisht ekziston një skript nisjeje që rregullon LD_LIBRARY_PATH në mënyrë që aplikacioni të ngarkojë gjithmonë skedarët e vet .so.

Në të gjitha këto raste, çelësi është që LD_LIBRARY_PATH përdoret në një i kufizuar dhe i saktë, e lidhur me një aplikacion specifik ose një mjedis testimi, jo si një ndryshore globale që ndikon në gjithçka që ekzekuton një përdorues ose në të gjithë sistemin.

Si të konfiguroni LD_LIBRARY_PATH në Linux hap pas hapi

Edhe pse i dini rreziqet, ju prapë dëshironi të përcaktoni LD_LIBRARY_PATH në mjedisin tuaj të përdoruesitNë shpërndarje si Ubuntu, është e zakonshme të modifikoni skedarin ~/.bashrc (duke supozuar që përdorni Bash si shell-in tuaj të parazgjedhur). Është skedari që ekzekutohet sa herë që hapni një terminal të ri interaktiv.

Për të filluar, hapni skedarin .bashrc me redaktorin tuaj të preferuarPërdoret në shumë tutoriale nano Për thjeshtësi, por mund të bëni të njëjtën gjë me vi, vim ose ndonjë redaktues teksti:

nano / .bashrc

Pasi të hapet, duhet të shtoni një rresht eksporti vendosja e variablit. Gjëja e rëndësishme këtu është të mos lini hapësira rreth shenjës së barazimit, sepse përndryshe Bash do ta interpretojë gabimisht. Një shembull i saktë do të ishte:

eksporto LD_LIBRARY_PATH=/home/osboxes/mukul

Në këtë rast, ne i themi sistemit që, kur kërkon biblioteka të përbashkëta, duhet të marrë parasysh direktorinë /home/osboxes/mukul para drejtorive standarde. Mund ta zëvendësoni me shtegun ku keni skedarët tuaj të personalizuar .so ose libraritë që dëshironi të përdorni.

Pasi të keni ruajtur ndryshimet dhe të dilni nga redaktori, duhet të konfigurimi i shell-it të rimbushjes që variabli i ri i mjedisit të hyjë në fuqi në sesionin aktual. Kjo zakonisht bëhet me:

burim ~ / .bashrc

Nëse doni të kontrolloni që gjithçka është aplikuar saktë, thjesht përdorni komandën echo Lidhur me variablin. Kjo do t'ju tregojë shtigjet që LD_LIBRARY_PATH përmban aktualisht:

jehonë $LD_LIBRARY_PATH

Nëse rreshti i daljes përfshin direktorinë që keni shtuar, kjo do të thotë që konfigurimi është ngarkuar saktë dhe ngarkuesi dinamik tani do ta marrë parasysh atë shteg kur të nisë programet.

Si të shtoni rrugë shtesë pa prishur asgjë

Shpesh nuk është me interes zëvendësoni plotësisht përmbajtjen e LD_LIBRARY_PATHNë vend të kësaj, shtoni një rrugë tjetër duke ruajtur ato ekzistuese. Kjo është e rëndësishme nëse libraritë e tjera janë konfiguruar tashmë dhe nuk doni të prishni varësitë nga aplikacionet e tjera.

Për të "zinxhiruar" rrugët, zakonisht përdoret një formë eksporti që shtoni një drejtori të re para variablit të mëparshëmPër shembull, nëse doni të shtoni /home/osboxes/sample Për atë që është përcaktuar tashmë, mund të shkruani diçka të tillë në tuajin .bashrc:

eksporto LD_LIBRARY_PATH=/home/osboxes/sample:${LD_LIBRARY_PATH}

Renditja ka rëndësi sepse ngarkuesi dinamik do të kërkojë së pari në /home/osboxes/sample dhe pastaj në adresat e mbetura që variabli tashmë i ka. Në këtë mënyrë, ju mund të futni një bibliotekë prioritare vetëm për teste të caktuara, duke e lënë pjesën tjetër të konfigurimit të paprekur.

Pasi ta modifikoni skedarin, mbani mend përsëri ekzekutoni komandën "burim" më ~/.bashrc për të aplikuar ndryshimet në terminalin aktual dhe kontrolloni përsëri me echo $LD_LIBRARY_PATH që itinerari i ri të shfaqet në krye të listës.

Rekomandohet shmangni ndryshimet e vazhdueshme në LD_LIBRARY_PATHÇdo modifikim i ekzekutuar dobët mund të ndikojë në programe që as nuk do t'i imagjinonit. Përdorni modelin "shto" me sintaksën. ${LD_LIBRARY_PATH} Ndihmon në ruajtjen e qëndrueshmërisë, por është më mirë të mos e teproni me përdorimin e saj.

Si funksionon kërkimi në bibliotekë dhe pse mund të jetë i rrezikshëm

Pas LD_LIBRARY_PATH ekziston një sjellje shumë specifike e ngarkuesit dinamik: përparësia e kërkimitShtigjet që vendosni në këtë variabël përpunohen përpara shtigjeve të parakompiluara dhe drejtorive standarde në sistemin tuaj, si p.sh. /lib, /usr/lib o /usr/lib64.

Problemi lind kur ato drejtori shtesë përmbajnë një bibliotekë me të njëjtin emër atë nga sistemi, por me një version të ndryshëm ose drejtpërdrejt të papajtueshëm. Ngarkuesi dinamik pa hezitim do të marrë atë që gjen i pari në LD_LIBRARY_PATH, edhe nëse aplikacioni ishte i lidhur fillimisht me një version tjetër.

Kjo situatë hap derën për disa lloje konfliktesh, përfshirë një nga siguria është mjaft seriozeNëse një përdorues keqdashës arrin t'ju bëjë të ekzekutoni një program me një LD_LIBRARY_PATH të manipuluar, ekziston mundësia që një bibliotekë keqdashëse të futet dhe të zëvendësojë versionin legjitim, duke ekzekutuar kod të padëshiruar.

Për këtë arsye, skedarët binare setuid ose setgid zakonisht injorojnë LD_LIBRARY_PATH plotësisht. Meqenëse ato funksionojnë me privilegje të larta, pranimi i shtigjeve arbitrare nga mjedisi i përdoruesit do të ishte një rrezik i madh; sistemi thjesht e hedh poshtë atë variabël në këto raste.

Përtej sigurisë, ekziston një aspekt i performancës dhe efikasitetit Diçka për t'u mbajtur mend. Çdo drejtori që shtoni në LD_LIBRARY_PATH e detyron ngarkuesin të përpiqet të hapë librari në atë shteg edhe nëse ato nuk janë realisht aty. Kjo rezulton në shumë thirrje të dështuara në open()të cilat kthejnë "ENOENT (Nuk ka skedar ose direktori të tillë)" dhe ngadalësojnë nisjen e aplikacioneve.

Sa më shumë rrugë të shtoni, dhe veçanërisht nëse ato janë drejtoritë e largëta (NFS)Sa më shumë që përdorni LD_LIBRARY_PATH, aq më shpejt do të nisin programet tuaja dhe aq më e madhe do të jetë ngarkesa në sistemin tuaj të skedarëve. Në mjedise të mëdha me qindra përdorues, përdorimi i tepërt i LD_LIBRARY_PATH mund të bëhet një pengesë e papritur.

Probleme tipike: mospërputhje dhe varësi të fshehura

Një tjetër efekt anësor shumë i zakonshëm është mospërputhje midis skedarëve binare dhe bibliotekaveLD_LIBRARY_PATH mund ta detyrojë një program të ngarkojë një version të ndryshëm të një biblioteke nga ai me të cilin është lidhur, dhe ato nuk janë gjithmonë 100% të pajtueshme në nivelin ABI ose të sjelljes.

Në rastin më të mirë, nëse ka një papajtueshmëri të qartë, aplikacioni Do të dështojë të fillojë ose do të rrëzohet shpejt, duke lënë gjurmë të dukshme të problemit. Por ajo që është vërtet e rrezikshme është kur biblioteka "funksionon pak a shumë", por Fillon të kthejë rezultate të pasakta ose të sillen në një mënyrë paksa të ndryshme, mjaftueshëm delikate sa të jetë e vështirë për t’u debuguar.

Një përdorim veçanërisht problematik është ai i përcaktoni LD_LIBRARY_PATH globalisht në profilet e përdoruesve ose, edhe më keq, në profilin e sistemit. Kur kjo ndodh, të gjitha aplikacionet që funksionojnë në atë seancë i ekspozohen atij konfigurimi, madje edhe ato që nuk janë projektuar kurrë për të punuar me ato shtigje shtesë.

Kur këto rrugë globale ndryshojnë ose pushojnë së ekzistuari, shumë skedarë binare mund të ndalo së punuari nga një ditë në tjetrën sepse, pa e vënë re askush, ata kishin filluar të mbështeteshin në atë "patch" të LD_LIBRARY_PATH për të gjetur bibliotekat e tyre.

Kjo shpjegon pse në shumë mjedise profesionale i kushtohet kaq shumë rëndësi përdorimit të variablit vetëm si mjet testimi i vetëm ose zgjidhje emergjentekurrë si një mekanizëm konfigurimi i qëndrueshëm afatgjatë.

Si të shihni se cilat biblioteka po përdoren në të vërtetë

Për të kuptuar plotësisht se si ndryshimet tuaja ndikojnë në LD_LIBRARY_PATH, është thelbësore të dini cilat biblioteka përdor secili ekzekutuesKëtu është vendi ku komandat si lddtë cilat japin një pamje mjaft të qartë të lidhjes dinamike.

Komanda ldd tregon, për një binar të caktuar, se cilat biblioteka dinamike i nevojiten. dhe nga cila rrugë po ngarkohen ato. Për shembull, nëse ekzekutoni:

ldd /usr/bin/file

Do të shihni një listë të rreshtave të tipit libmagic.so.1 => /usr/lib64/libmagic.so.1, së bashku me rezolutën e linux-vdso.so.1, libc.so.6 dhe vetë karikuesi dinamik. Ky informacion ju jep një foto statike të varësive kryesore të skedarit ekzekutues.

Megjithatë, ka raste kur një bibliotekë e përbashkët ngarkon biblioteka të tjera gjatë kohës së ekzekutimit (për shembull, përmes dlopen()), dhe këto nuk pasqyrohen në rezultatin e ldd. Për të parë një pamje më të plotë, është e nevojshme të shqyrtojmë se cilët skedarë .so janë hartëzuar në të vërtetë në hapësirën e adresave të një procesi në ekzekutim.

Në disa sisteme të tipit Solaris, komanda ekziston pldd`ldd` rendit libraritë dinamike të ngarkuara nga një proces bazuar në PID-in e tij. Kur përdoret në një program si Bash, mund të shihni se si libraritë e tjera, të tilla si modulet e konvertimit të karaktereve, shtohen në ato të renditura nga `ldd`. Modulet NSS për zgjidhjen e përdoruesve dhe grupeve.

Në Linux-in e pastër, pldd nuk është gjithmonë i disponueshëm si një skedar binar standard, por Ka skripte në Perl ose mjete të tjera që nxjerrin informacionin nga /proc/<PID>/mapsduke arritur një efekt të ngjashëm. Në këtë mënyrë mund të kontrolloni nëse cilësimet tuaja LD_LIBRARY_PATH kanë shkaktuar ngarkim të papritur të bibliotekave.

Mënyra më të pastra për të shmangur mbështetjen te LD_LIBRARY_PATH

Rekomandimi i përgjithshëm kur filloni të grumbulloni zgjidhje alternative me LD_LIBRARY_PATH është i thjeshtë: Përdoreni sa më pak të jetë absolutisht e nevojshme.Çdo rrugë që shtoni është një burim potencial gabimesh, konfliktesh versionesh dhe problemesh me performancën, kështu që ia vlen të merrni në konsideratë alternativa më të fuqishme.

Nëse i kompiloni aplikacionet tuaja (për shembull, duke ndjekur Linux nga ScratchKeni në dispozicion përdorimin e opsioni -rpath i lidhësitKy opsion ju lejon të ngulisni shtegun drejt bibliotekave nga të cilat varet direkt në skedarin ekzekutues, në mënyrë që skedari binar të dijë se ku t'i gjejë ato pa pasur nevojë të prekë variablat globale të mjedisit.

Një shembull tipik do të ishte diçka si:

cc -o myprog obj1.o … objn.o -Wl,-rpath=/shtegu/për në/lib -L/shtegu/për në/lib -lmylib

Me këtë, lidhësi shton /path/to/lib për në rrugën e ekzekutimit të skedarit ekzekutuesNëse keni nevojë për rrugë të shumta, është mjaft e përshtatshme të përdorni ndryshoren e mjedisit. LD_RUN_PATHtë cilin e kupton edhe linkeri dhe të cilin mund ta populloni me një listë drejtorish të ndara me dy pika.

Mund të bësh, për shembull:

eksporto LD_RUN_PATH=/shtegu/për në/lib1:/shtegu/për në/lib2:/shtegu/për në/lib3
cc -o myprog obj1.o … objn.o -L/shtegu/për në/lib1 -lmylib1 -L/shtegu/për në/lib2 -lmylib2

Pas kompilimit, mund të kontrolloni me ldd që binarja Ai zgjidh saktë të gjitha bibliotekat e tij pa u mbështetur në LD_LIBRARY_PATH. Nëse shfaqet ndonjë gabim "nuk u gjet", duhet të kontrolloni Makefile dhe konfigurimin LD_RUN_PATH.

Kur nuk mund ta rikompiloni, ekziston mundësia për të përdor mjete si chrpath për të modifikuar rrugën e ekzekutimit që është tashmë e integruar në vetë skedarin ekzekutues. Kjo teknikë ka kufizime: mund të mbishkruash vetëm vargun ekzistues, jo ta zgjerosh atë, dhe nëse skedari binar nuk kishte një rrugë ekzekutimi të përcaktuar, nuk ka asgjë për të ndryshuar.

Përdorimi i skripteve të mbështjellësve dhe bërja e rregullimeve specifike nga rreshti i komandës

Nëse as lidhja me -rpath dhe as chrpath nuk është një mundësi, prapëseprapë mund të përdorni mbështjellësi i skripteve Ata duhet ta përshtatin LD_LIBRARY_PATH vetëm për një aplikacion specifik dhe asgjë më shumë. Është një qasje shumë më pak ndërhyrëse sesa ndërhyrja në profilin e përdoruesit.

Një mbështjellës tipik në guaskë do të dukej diçka e tillë:

# / Bin / sh
LD_LIBRARY_PATH=/shtegu/për në/lib1:/shtegu/për në/lib2:/shtegu/për në/lib3
eksporto LD_LIBRARY_PATH
exec /path/to/bin/myprog «$@»

Me këtë qasje, variabli mjedisor "Ndotet" vetëm për myprog Dhe, si rrjedhojë, për çdo proces fëmijë që ekzekutohet, por jo për komandat e tjera që ekzekutoni në seancën tuaj. Është një zgjidhje mjaft e pranueshme kur jeni të detyruar të punoni me versione specifike të bibliotekës për një aplikacion të caktuar.

Një tjetër mundësi shumë e dobishme për teste të shpejta është përdorimi i komandës zili Për të përcaktuar LD_LIBRARY_PATH vetëm për një ekzekutim të vetëm. Për shembull:

env LD_LIBRARY_PATH=/shtegu/për në/lib1:/shtegu/për në/lib2 ./myprog

Në këtë mënyrë zbatohet variabli vetëm për atë thirrje de myprogDhe kur të përfundojë, shell-i juaj mbetet i paprekur, pa asnjë gjurmë shtigjesh të çuditshme që mund të ndikojnë në komandën tjetër që ekzekutoni.

Ajo që rekomandohet fuqimisht të shmanget është të bësh diçka si:

eksporto LD_LIBRARY_PATH=/shtegu/për në/lib1:/shtegu/për në/lib2
./myprog

Ky model lë LD_LIBRARY_PATH përcaktuar për të gjitha porositë pasuese që e nisni nga ai terminal, gjë që mund të shkaktojë efekte anësore që janë shumë të vështira për t'u ndjekur më vonë. Për teste të izoluara, thirrja me env Është shumë më i pastër.

Praktikat e mira dhe gabimet e zakonshme që duhen shmangur

Një rekomandim i artë i pranuar gjerësisht është Mos e përcaktoni kurrë LD_LIBRARY_PATH në profilet e hyrjesas skedarë përdoruesi dhe as të sistemit. Me fjalë të tjera, shmangni shtimin e tij në skedarë si ~/.bash_profile, ~/.profile, /etc/profile ose te ngjashme.

Kur një variabël kaq i ndjeshëm vendoset globalisht, të gjitha aplikacionet e nisura nga ai përdorues do të përdorin ato shtigje shtesë, madje edhe ato të konfiguruara në mënyrë të përsosur për të punuar me libraritë e sistemit. Duke e zvogëluar fushëveprimin e saj në skripte specifike ose ekzekutime të njëhershme Është gjithmonë një bast shumë më i sigurt.

Është gjithashtu e mençur të jesh i kujdesshëm ndaj instalues ​​të palëve të treta Gjatë instalimit, ata mund t'ju kërkojnë të shtoni LD_LIBRARY_PATH në profilin tuaj, ose mund ta bëjnë këtë për ju globalisht. Në shumicën e rasteve, kjo është një rrugë e shkurtër e lehtë për ofruesin, por do të shkaktojë probleme për mjedisin tuaj në planin afatmesëm.

Sa herë që është e mundur, ia vlen të luftosh pak më fort dhe kërkoni alternativa të pastra: rregulloni rrugën e ekzekutimit të skedarit të ekzekutueshëm, instaloni bibliotekat në një drejtori standarde, përdorni mekanizma modernë paketimi ose enkapsuloni aplikacionin me një mbështjellës skripti në vend që të prekni mjedisin e përgjithshëm.

Nëse jeni të detyruar të përdorni variablin, përpiquni të mbani rrugët më i kufizuar dhe specifik Nëse është e mundur, minimizoni numrin e drejtorive dhe shmangni me çdo kusht shtigjet e vendosura në sisteme skedarësh të largëta, përveç nëse është absolutisht e nevojshme.

Me gjithë këto që u thanë, LD_LIBRARY_PATH mbetet si një mjet i fuqishëm por delikatËshtë shumë i dobishëm për testimin e versioneve të reja të bibliotekave, zhvendosjen e skedarëve të vjetër .so ose ndërtimin e mjediseve të pavarura për aplikacione të mëdha, por përdorimi i tij pa kriter mbart rreziqe sigurie, probleme të performancës dhe mospërputhje që janë të vështira për t'u debuguar. Të kuptuarit se si funksionon ngarkuesi dinamik, mbështetja në alternativa si -rpath, LD_RUN_PATH ose skripte mbështjellëse, dhe kufizimi i kësaj variabli në kontekste shumë specifike është mënyra më e mirë për të përfituar nga LD_LIBRARY_PATH pa e kthyer atë në një kurth për sistemin tuaj.