Qual è l'ordine in cui il linker dinamico di Linux cerca i percorsi?

Questo non è un duplicato perché si tratta di una peculiarità che ho notato quando uso /etc/ld.so.conf.

Per ottenere i percorsi in cui il linker dinamico cerca le librerie, eseguo il comando ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Quando /etc/ld.so.confnon contiene percorsi elencati. L'output del comando precedente è

/lib
/usr/lib

Ho pensato che /libprima cercasse e poi /usr/lib. Quando aggiungo un nuovo percorso, ad esempio /usr/local/lib, /etc/ld.so.confae poi rifaccio /etc/ld.so.cache, l'output da ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"diventa

/usr/local/lib
/lib
/usr/lib

Lo trovo strano perché se ho ragione che l'ordine in cui le directory elencate sono ricercate è dall'alto verso il basso, allora vengono cercate altre directory prima /libe /usr/lib. Che le directory aggiuntive vengano ricercate prima delle directory attendibili non è strano da solo, ma quando /libviene cercato prima /usr/lib, è strano perché /bin& /sbinvengono cercate dopo /usr/bine /usr/sbinin PATH.

Anche se i percorsi elencati ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"fossero cercati dal basso verso l'alto, sarebbe comunque un ordinamento distorto perché le directory aggiuntive verrebbero ricercate dopo quelle fidate mentre /libsarebbero state cercate dopo /usr/lib.

Quindi, qual è l'ordine in cui ld.socercano i percorsi per le librerie? Perché viene /libcercato prima /usr/lib? In caso contrario, perché vengono ricercate ulteriori directory /lib?

L'ordine è documentato nel manuale del linker dinamico, che è ld.so. È:

1. directory da LD_LIBRARY_PATH;
2. directory da /etc/ld.so.conf;
3. /lib;
4. /usr/lib.

(Sto semplificando un po ', vedi il manuale per i dettagli completi.)

L'ordine ha senso se si considera che è l'unico modo per sovrascrivere una libreria in una posizione predefinita con una libreria personalizzata. LD_LIBRARY_PATHè un'impostazione utente, deve precedere gli altri. /etc/ld.so.confè un'impostazione locale, precede l'impostazione predefinita del sistema operativo. Quindi, come utente, se voglio eseguire un programma con una versione diversa di una libreria, posso eseguire il programma LD_LIBRARY_PATHcontenente il percorso di quella diversa versione della libreria. E in qualità di amministratore, posso mettere una versione diversa della biblioteca /usr/local/libe la lista /usr/local/libin /etc/ld.so.conf.

La fiducia non entra in questo. Qualsiasi directory elencata in questo percorso di ricerca deve essere considerata attendibile, poiché qualsiasi libreria potrebbe finire per essere caricata da lì. In teoria, potresti elencare i nomi delle librerie utilizzate da tutti i programmi "che richiedono più fiducia" sul tuo sistema e assicurarti che tutte queste librerie siano presenti nelle directory "più affidabili", e quindi le directory "meno affidabili" non lo farebbero essere utilizzato se sono venuti dopo le directory più attendibili nel percorso di ricerca, ad eccezione dei programmi che "richiedono meno fiducia". Ma sarebbe estremamente fragile. Sarebbe anche abbastanza inutile: se un attaccante può iniettare un valore di LD_LIBRARY_PATHo un elemento di /etc/ld.so.conf, sicuramente hanno una strada più diretta per eseguire codice arbitrario, come iniettare un valore di PATH, diLD_PRELOAD, ecc. La fiducia nel percorso di caricamento della libreria è importante quando l'esecuzione attraversa un limite di fiducia, ovvero quando si esegue un programma con privilegi aggiuntivi (ad es. programma setuid / setgid o via sudo). Quello che succede in questo caso è che LD_LIBRARY_PATHè oscurato.

Per quanto riguarda /libvs /usr/lib, non importa molto: sono forniti dalla stessa entità (il sistema operativo) e non dovrebbe esserci una libreria presente in entrambi. Ha senso elencare per /libprimo perché fornisce un (molto piccolo) vantaggio in termini di prestazioni: le librerie più utilizzate, in particolare le librerie utilizzate da piccoli programmi di base (per i quali il tempo di caricamento è una frazione maggiore del tempo di esecuzione totale rispetto a grandi, lunghi -running program), si trovano in /lib.