Em que ordem o vinculador dinâmico do Linux pesquisa caminhos?

Isso não é uma duplicata porque está lidando com uma peculiaridade que notei quando uso /etc/ld.so.conf.

Para obter os caminhos que as pesquisas vinculador dinâmico em para bibliotecas, eu executar o comando ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g". Quando /etc/ld.so.confnão há caminhos listados nele. A saída do comando anterior é

/lib
/usr/lib

Achei que ele procurava /libprimeiro e depois /usr/lib. Quando adiciono um novo caminho, como /usr/local/lib, para /etc/ld.so.confe, em seguida /etc/ld.so.cache, refiro , a saída de ldconfig -v | grep -v "^"$'\t' | sed "s/:$//g"se torna

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

Acho isso estranho, porque, se eu estiver certo de que a ordem em que os diretórios listados são pesquisados ​​é de cima para baixo, os diretórios adicionais serão pesquisados ​​antes /libe /usr/lib. O fato de os diretórios adicionais serem pesquisados ​​antes dos diretórios confiáveis ​​não é estranho por si só, mas quando /libé pesquisado antes /usr/lib, isso é estranho porque /bin& /sbiné pesquisado após /usr/bin& /usr/sbinin PATH.

Mesmo que os caminhos listados por ldconfig -v | grep -Ev "^"$'\t' | sed "s/:$//g"fossem pesquisados ​​de baixo para cima, ainda assim seria uma ordenação distorcida, porque diretórios adicionais seriam pesquisados ​​pelos confiáveis ​​e /lib, depois, pesquisados /usr/lib.

Então, qual é a ordem em que ld.soprocura caminhos para bibliotecas? Por que é /libpesquisado antes /usr/lib? Caso contrário, por que diretórios adicionais são pesquisados /lib?

O pedido está documentado no manual do vinculador dinâmico, que é ld.so. Isto é:

1. diretórios de LD_LIBRARY_PATH;
2. diretórios de /etc/ld.so.conf;
3. /lib;
4. /usr/lib.

(Estou simplificando um pouco, consulte o manual para obter todos os detalhes.)

A ordem faz sentido quando você considera que é a única maneira de substituir uma biblioteca em um local padrão por uma biblioteca personalizada. LD_LIBRARY_PATHé uma configuração do usuário, tem que vir antes dos outros. /etc/ld.so.confé uma configuração local, vem antes do padrão do sistema operacional. Portanto, como usuário, se eu quiser executar um programa com uma versão diferente de uma biblioteca, posso executar o programa LD_LIBRARY_PATHcontendo o local dessa versão de biblioteca diferente. E como administrador, posso colocar uma versão diferente da biblioteca em /usr/local/libe lista /usr/local/libem /etc/ld.so.conf.

A confiança não entra nisso. Qualquer diretório listado nesse caminho de pesquisa deve ser confiável, porque qualquer biblioteca pode acabar sendo carregada a partir daí. Em teoria, você pode listar os nomes de bibliotecas usados ​​por todos os programas “exigindo mais confiança” em seu sistema e garantir que todas essas bibliotecas estejam presentes nos diretórios “mais confiáveis” e, em seguida, os diretórios “menos confiáveis” não ser usado se eles vierem após os diretórios mais confiáveis ​​no caminho de pesquisa, exceto os programas "que exigem menos confiança". Mas isso seria extremamente frágil. Também seria inútil: se um invasor puder injetar um valor LD_LIBRARY_PATHou um elemento dele /etc/ld.so.conf, certamente terá uma rota mais direta para executar código arbitrário, como injetar um valor de PATH, deLD_PRELOAD, etc. A confiança no caminho de carregamento da biblioteca importa quando a execução ultrapassa um limite de confiança, ou seja, ao executar um programa com privilégios adicionais (por exemplo, programa setuid / setgid ou via sudo). O que acontece nesse caso é que LD_LIBRARY_PATHestá apagado.

Quanto ao /libvs /usr/lib, não importa muito: eles são fornecidos pela mesma entidade (o sistema operacional) e não deve haver uma biblioteca presente em ambos. Faz sentido listar /libprimeiro porque fornece uma (muito pequena) vantagem de desempenho: as bibliotecas mais usadas, especialmente as bibliotecas usadas por pequenos programas básicos (para os quais o tempo de carregamento é uma fração maior do tempo total de execução do que grandes, longos -running), estão localizados em /lib.